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

From: Randall Stewart <[email-masked]>
Date: Tue, 06 Nov 2001 07:55:41 -0600

Ivan:

see below..

[email-masked] wrote:
> 
> > -----Original Message-----
> > From: ext Randall Stewart [mailto:[email-masked]]
> > Sent: 06. November 2001 14:44
> > To: sigtran
> > Cc: Arias-Rodriguez Ivan (NRC/Helsinki);
> > [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [Tsvwg] Re: M2PA: User Level Acknowledgements
> >
> >
> > Brian:
> >
> > If the WG feels this is the right idea I have no problem to changing
> > this wording to:
> >
> > "
> > Note: Anytime the receivers rwnd is 0, the receiver MUST drop
> >       the DATA chunk without acknowledgment of the new DATA
> >       chunk (since it has no room to receive the data nor
> > validate it).
> >       However the receiver MUST still send an acknowledgment showing
> >       the new chunk as still missing with a r_wnd update following
> >       the delayed acknowledgment guidelines specified below.
> > "
> >
> > As Kachong said, this is a minor point. You should have specified
> > that is what you wanted in the first place... all you would
> > have had to do is quote the sentence and ask it to be changed
> > to a MUST...
> >
> > What does the rest of the working group feel?
> 
>         I think it is nice... Just a minor question. "nor validate it", do
> you mean calculating the checksum? I guess you have to do that before you
> ever realize there is a DATA chunk inside... If so, I would take those three
> words... I would make some minor spell changes:
> 
> "
> 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. 

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. 
"

R
> 
>         Brian? Randall?
> 
>         BR Iván Arias Rodríguez
> 
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Ivan,
> > >
> > > This only says that if I choose to drop it (MAY) that I MUST still
> > > send a SACK.  There is nothing in these words precluding an
> > > implementation from Cum Acking the data while still advertising
> > > a_rwnd = 0.
> >
> >
> > I don't like the above since now you get the implementation
> > lying about where the cum-ack is. This is much harder
> > to implement... if we go down this type of route then
> > I think we should just require the chunk to be dropped.
> >
> > We might need to add some words about the fact that a probe
> > chunk SHOULD NOT cause any adjustment to the cwnd as would
> > a normal time-out. At least from what Kacheong said this is
> > how TCP works.. so we want to make SCTP similar here..
> >
> > R
> >
> > R
> >
> >
> >
> > >
> > > It that is what was intended, I suggest the following sentence
> > > be added:
> > >
> > >    The receiver MUST NOT cummulatively acknowledge any DATA
> > >    (i.e., the receiver MUST NOT move the cumulative TSN ack
> > >    point) while advertising an a_rwnd of zero.
> > >
> > > Clear?
> > >
> > > --brian
> > >
> > > [email-masked] wrote:        (Tue, 06 Nov
> > 2001 14:09:47)
> > > >       Brian, please, please, please, read what is
> > written... Maybe you
> > > > just have a problem to understand the difference between
> > saving the TSN in
> > > > your buffer (the MAY), and not acknowledge its receipt
> > (the MUST)... I quote
> > > > (again):
> > > >
> > > > > > "
> > > > > > Note: Anytime the receivers rwnd is 0, the receiver MAY drop
> > > >                                                             ^^^^
> > > > > > the DATA chunk without acknowledgment of the new DATA
> > > >                    ^^^^^^^
> > > > > > chunk (since it has no room to receive the data nor
> > validate it).
> > > > > > However the receiver MUST still send an acknowledgment showing
> > > >                          ^^^^
> > > > > > the new chunk as still missing with a r_wnd update following
> > > >                   ^^^^^^^^^^^^^^^^
> > > > > > the delayed acknowledgment guidelines specified below.
> > > > > > "
> > > >
> > > >       I don't know if it would be better for you something like:
> > > >
> > > > Note: Anytime the receiver's rwnd is 0, the receiver MAY drop
> > > > the DATA chunk (since it has no room to receive the data).
> > > > However the receiver MUST still send an acknowledgement showing
> > > > the new chunk as still missing with an a_rwnd update and following
> > > > the delayed acknowledgement guidelines specified below.
> > > >
> > > >       Any better? (but is still says exactly the same as
> > before)...
> > > >
> > > > ... snip...
> > > >
> > > >       BR Iván Arias Rodríguez
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > --
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> >
> >
> > ---
> > 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

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 06 Nov 2001 12:10:54 -0600

Hi, Randy:

Randall Stewart wrote:
...
> I am fine with the above.  We could proably drop the (since...) it

The above change sounds ok with me.

> 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.

This change is far more fundamental than the previous one. My opinion is
the normal CC should apply and the cwnd should gradually degrade.

-Qiaobing

---

---

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

Q:

Comments below...

> the normal CC should apply and the cwnd should gradually degrade.

I have thought on this one for a while and looked a bit into
the BSD code that does the probing.

It does the above as well. The reason being that:

The ack clock is not really lost, since you are maintaining sending
a packet every RTO... i.e. our probe. Also, think for a moment on
a case where you had a high volume cwnd 500k like you say above. Now
all of a sudden you slow sending down to 1 Packet every RTO. Just
enough to not get a reduction via the not sending every RTO. You
stay like this for 10 minutes.. Then you start sending full blast
again...

What is different between the two cases? 

The only difference would be the exponential backoff of the RTO
while you await the rwnd to free...

And as I said, TCP does this today so I would prefer NOT to
handicap SCTP by not staying on the same footing as TCP...

R

---