Subject: Re: [Tsvwg] Re: M2PA: User Level Acknowledgements

From: Qiaobing Xie <[email-masked]>
Date: Tue, 06 Nov 2001 14:48:41 -0600

[email-masked] wrote:
> 
>         Hi all,
> 
> > -----Original Message-----
> > From: ext Qiaobing Xie [mailto:[email-masked]]
> > Sent: 06. November 2001 20:11
> > To: Randall Stewart
> > Cc: Arias-Rodriguez Ivan (NRC/Helsinki);
> > [email-masked];
> > [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [Tsvwg] Re: M2PA: User Level Acknowledgements
> >
> >
> > Hi, Randy:
> >
> > Randall Stewart wrote:
> > ...
> > > > "
> > > > Note: Anytime the receiver's rwnd is 0, the receiver MUST drop
> > > >       the DATA chunk without acknowledgement of the new DATA
> > > >       chunk (since it has no room to receive the data).
> > > >       However the receiver MUST still send an
> > acknowledgment showing
> > > >       the new chunk as still missing with a rwnd update
> > and following
> > > >       the delayed acknowledgment guidelines specified below.
> > > > "
> > >
> > > I am fine with the above.  We could proably drop the (since...) it
> > > does not add anything.
> >
> > The above change sounds ok with me.
> >
> > >
> > > We also probably need some wording for the sender side
> > something like:
> > >
> > > "
> > > When a sender is probing for a change in space in the rwnd (where
> > > the peer has set the a_rwnd to 0 and no data is inflight), if
> > > the single probe chunk is sent and then subsequently time's out (due
> > > to no change in the rwnd) the sender SHOULD NOT apply any
> > > adjustment to the cwnd (as described in 7.2.3) but it MUST
> > > backoff the RTO time by doubling the current value.
> > > "
> >
> > I am a little concerned about this one, though. There is a danger of
> > flooding the network with this change. For instance, if cwnd
> > was at 500k
> > the moment the receiver first slammed its a_rwnd down to 0, and the
> > a_rwnd remains at 0 for 10 min before it opens up again, and
> > during this
> > 10 min period the sender is probing with a 1k (=PMTU) chunk.
> > Then, there
> > is the possibility that the sender will flood the network
> > with upto 500k
> > data at the moment the a_rwnd opens up again. This doesn't sound right
> > to me. 10 min is a long time and the 500k cwnd should be discarded by
> > then.
> 
>         But in that case, the other rule about the idle addresses will make
> the work... Ok, we have the "MUST" vs. "SHOULD" war here again...

This to me is another argument *against* the proposed change: when the
sender is doing nothing but retransmitting a DATA chunk over and over
for probing the peer a_rwnd, the destination addr is considered idle
according to the "idle" definition in the RFC. Therefore, the cwnd
degradation rule for idle address should apply.

> 
>         In any case, I don't think people will stay 10 mins with the rwnd
> set to 0... It is in any case likely that the whole association will be tore
> down before that. As the retransmitted DATA chunk is not liable to be used
> to measure the RTT, I think we will be sending HEARTBEATS, and even if we
> have to backoff RTO it will be set every now and then to RTO.min... With 8
> retransmissions before we give up I don't think the association will survive
> more than 30 seconds...
> 
>         Moreover, that 0 a_rwnd story will be mostly used in that changeover
> situation, which should last no more than few milliseconds...

We shouldn't modify the base protocol just for the M2PA changeover.

-Qiaobing

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 06 Nov 2001 16:16:31 -0600

> We shouldn't modify the base protocol just for the M2PA changeover.

This is NOT for M2PA. This is to make SCTP probing work the SAME
EXACT way TCP does..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Tue, 06 Nov 2001 16:33:45 -0600

"Brian F. G. Bidulock" wrote:
> Oh?  I understood that TCP allows new data to be acked during
> the probe.  Why would SCTP not?
> 

Brian:

The goal was to make Congestion Control work the same
as TCP. In this case dropping the chunk is one of the
two options that TCP does... choosing one does not effect
congestion control..

On the other hand, reducing the cwnd does effect cc and 
causes SCTP to be sub-optimal in comparison to TCP in this
case...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 16:27:00 -0600

Randall,

Randall Stewart wrote:                                    (Tue, 06 Nov 2001 16:16:31)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/