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

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 6 Nov 2001 09:24:33 -0800

Folks,

Sounds like we're reaching an agreement here.  This
text would, I assume, go into the "bakeoff results"
draft and eventually into the next version of SCTP?
I would support that (dropping the "since..." note).

Cheers,

Lyndon

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 5:56 AM
To: sigtran
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: M2PA: User Level Acknowledgements

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]

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

---

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

I think you meant implementors guide :>

R