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

From: [email-masked]
Date: Tue, 6 Nov 2001 23:42:38 +0200

Hi Qiaobing! See some comments below...

> -----Original Message-----
> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: 06. November 2001 22:49
> To: sigtran
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] Re: M2PA: User Level Acknowledgements
> 
> 
> [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.

	The more I think about this the more I'm against that second
change... If the rwnd will be set to 0 just for few time, then T3 won't even
expire... And if they are just leaving a congestion situation, it would
probably help to reduce cwnd...

	BR Iván Arias Rodríguez

> -Qiaobing
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

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

---

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

> probably help to reduce cwnd...

Ivan/Qiaobing:

Then please tell me why TCP does this. TCP does NOT reduce
cwnd on a probe and leaves everything as is.
The goal of SCTP was to get the same behavior for CC as
TCP.... I do not see why we should penalize SCTP and NOT
do what TCP does...

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 6 Nov 2001 18:11:14 -0500 (EST)

> [email-masked] wrote:
<snip>
> TCP.... I do not see why we should penalize SCTP and NOT

I agree with Randall here, but not just because it mimics what TCP does.
Having an rwnd of 0 does not alone imply congestion in the network, it
implies a full buffer at the receiver. In other words, it is a flow
control issue and not a congestion control issue. Therefore, cwnd should
not be modified.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 6 Nov 2001 16:02:10 -0800 (PST)

> TCP.... I do not see why we should penalize SCTP and NOT

Oops, I may have misled Randy.  I think I need to get this
straight.  While zero window probe itself does not affect
cwnd, but the normal sending code which checks for how long
the pipe has been emptied will kick in and reduce the cwnd.
There is no special check here, just the normal code path.

There may be an implementation which has a timer fires a little
bit early such that by the time the sending code is executed,
it thinks that the pipe has not been emptied for one RTO.  Then
cwnd will not be reduced.  But I doubt that there is such a
stack.

So I think nothing special needs to be done or changed.  The
normal code path will take care of that.  The issue to me is
how to express this in words precisely.

							K. Poon.
							[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Tue, 06 Nov 2001 18:20:03 -0600

> how to express this in words precisely.
I have no problem with that.. I just don't want the window
probe code reducing the cwnd.

R