Re: [Tsvwg] SCTP: Data chunk in flight when a_rwnd = 0

[Randall Stewart <[e-mail]>]

"Brian F. G. Bidulock" wrote:
> 
> Chip,
> 
> On Mon, 05 Nov 2001, Chip Sharp wrote:
> 
> > A few thoughts:
> >
> > The spec says the sender can have *one* DATA chunk in flight, regardless of
> > rwnd.
> >
> > If the sender reaches the point that rwnd=0 due to outstanding DATA chunks
> > that have not been SACKED, then it will stop transmitting since DATA chunks
> > are already in flight.  If the sender receives a SACK with a_rwnd=0 and the
> > SACK does not acknowledge all DATA chunks in flight, then the sender can't
> > send any more DATA chunks based on the above rule.
> 
> But the receiver is not allowed to not acknowledge DATA chunks...
> 

I fail to understand why you continue to beat a dead horse? I have
said that the next implementors guide.. which IS a supplement to
the RFC and the MUST's etc in this WILL apply just as forcefully
as RFC2960 (when we are done with it) .. will have the wording
to allow the receiver to drop the chunk.. 

Continuing to rant about something that is going to be fixed
and will be available in the implementors guide draft is
non-productive and a waste of everyones cycles..


> > Thus, the only thing the sender has control over is whether or not it can
> > send 1 DATA chunk when rwnd=0 and there are no outstanding DATA chunks. If
> > the sender doesn't probe for a change in rwnd, it will never be able to
> > transmit new data (deadlock).
> 
> It can send new data when the receive opens up a_rwnd.  There is only a
> deadlock situation if a SACK is lost (the one that opened up a_rwnd).
> Thus the need to force a SACK or two out of the receiver ever so often.
> DUP segments in TCP do this just fine.  DUP TSNs in SCTP would work as
> well (they force an immediate SACK which either contains a_rwnd = 0 or
> some other value).
> 
And allowing a receiver to DROP a segment due to lack of
buffer space and SACK with no update does the same thing. This
is similar to what TCP does. Yes some implementations do send
dup data.. others do not... the spec will be made similar..


> > If the receiver does not acknowledge this DATA chunk, the sender cannot
> > transmit any more DATA chunks since the DATA chunk is "in flight" until
> > acked.
> 
> But if the receiver is required (or permitted) to ack the DATA chunk,
> DATA will flow.
> 

see above..

> > If the receiver does transmit a SACK with a_rwnd=0, the receiver will still
> > receive new DATA chunks that were in flight prior to the sender receiving
> > the SACK.  Thus, the receiver must be able to deal with the situation in
> > which it receives new DATA chunks after sending a_rwnd=0 regardless of the
> > operation of the sender.
> 
> This is not the required behavior.  It is required that acks of data in
> flight also be withheld once a_rwnd has been advertized zero.  Otherwise
> each of these DATA chunks will be lost to the network with no copy in
> the sender's retransmission buffer for retrieval and retransmission on an
> alternate association.


You make no sense above. If data is dropped (due to lack of buffer
space) and SACK are sent duplicating, if you will, the last SACK
sent aka same cum-ack, a-rwnd-0 + whatever gap-ack blocks still
present... It will keep the sender happy... all is well AND
it will let the receiver clear its buffer problem.

> 
> >
> > The only problem seems to be whether or not the receiver acknowledges DATA
> > chunks received after it sends out a_rwnd=0.
> 
> No data chunks can be acknowledged after it asserts a_rwnd = 0, it doesn't
> matter when it hits the line or gets to the other side.
> 
> >       * No:  The receiver will receive a periodic retransmission of one of
> > the missing DATA chunks on timeout.
> >       * Yes: The receiver will receive a new DATA chunk per round-trip time
> > as each single new DATA chunk is acked.
> 
> Plus the data chunks in flight which are not to be acked.  Each of these
> messages is a message lost to SS7 with M2PA.  MTP3 conformace requires that
> no messages (0, zero, nicht, nil) messages be lost in these changeover
> scenarios.  One message gone astrasy and MTP3 cannot conform over M2PA.
> 
> If SCTP stops cum acking on a_rwnd = 0 assertion all is well.  A MAY does
> not do M2PA any good here...

Either a implementation will STOP accepting new data and cum-ack
the way things were when rwnd=0 occured, and thus NO DATA is
lost... OR the implementation will pull the DATA in and SACK it..

In either case NO data is lost... 0, zero , nicht, nil...

R

> 
> --brian
> 
> >
> >
> > Chip
> >
> > At 03:13 AM 11/4/2001, Brian F. G. Bidulock wrote:
> > >Vern,
> > >
> > >On Sat, 03 Nov 2001, Vern Paxson wrote:
> > >
> > > > > Have I missed somewhere in the RFC where it mentions that
> > > > > the receiver can refuse to acknowledge received DATA chunks
> > > > > containing new data when it is advertising a receive window
> > > > > of 0?
> > > > >
> > > > > Or was it the intention of SCTP that it not permit a
> > > > > receiver to stop traffic by setting a_rwnd = 0?
> > > >
> > > > The intention was that the sender is always allowed to *try* sending a
> > > > bit of data beyond the window to serve as a probe to see if the window
> > > > has in fact opened up, but that also the receiver can indeed stop traffic
> > > > by setting the advertised window to 0.
> > > >
> > > > The sender might not have previously-transmitted data lying around with
> > > > which to make its attempt, so it's allowed to do it with new data.
> > >
> > >Actually, one doesn't need new or old data, just an already
> > >acked TSN.  A duplicate TSN will have the effect you are
> > >looking for without needing the old data (whatever data is
> > >included must be discarded).
> > >
> > > > The
> > > > receiver does not have to accept this data; if it doesn't, it should send
> > > > a SACK describing what data it has received & accepted, along with a window
> > > > advertisement.
> > >
> > >Although this makes, sense, the RFC does not permit the receiver
> > >to refuse acknowledgement of new DATA whether a_rwnd = 0 or not
> > >(Section 6.2).  Nor is it described anywhere that the sender of
> > >these probing packets is permitted to stop pegging association
> > >and path retransmit counters, even if the other side does withhold
> > >acknolwedgements.
> > >
> > > >
> > > > That said, the above is my recollection of the intent when we added the
> > > > rule in question - I haven't looked through the RFC to see how it has been
> > > > written up.
> > >
> > >Take a look.  I don't think that the current text in the RFC
> > >achieves this intent in several respects:
> > >
> > >     1.) It does not permit the endpoint to withhold acks of
> > >         new data when a_rwnd = 0 as you describe.  (Section 6.2
> > >         says that every new DATA chunk must be acknolwedged and
> > >         sets upper bounds on the time limit for acknowledgement.)
> > >
> > >     2.) It does not permit the endpoint to send SACK immediately
> > >         when receiving new data while a_rwnd = 0 as you describe.
> > >         (Section 6.2 says that the enpoint should only SACK
> > >         immediately on duplicates, gaps, or to update a_rwnd, and
> > >         should ack every second DATA chunk otherwise.)
> > >
> > >     3.) When "probing" in this fashion, the transmitter is still
> > >         required to run RTO and perform cwnd calculations also
> > >         to peg association and path retransmits.  This could lead
> > >         to failure of the association (depending on heartbeat
> > >         intervals) if the receiver is withholding acks in the
> > >         fashion that your describe.
> > >
> > >Although I agree that it should be the intention, the current
> > >text in the RFC certainly does not have the effect of stopping
> > >traffic flow.  The above three things need to be corrected first:
> > >the receiver advertising a_rwnd = 0 must be permitted to withhold
> > >acknolwedgements, required to SACK immediately, and the transmitter
> > >probing a peer adversiting a_rwnd = 0 should not perform congestion
> > >or retransmission calcaltations on the "probes".
> > >
> > >Rather than changing all those things in the RFC, it would probably
> > >be better to take the opposite interpretation and say that the
> > >transmittter MUST NOT send new data (as the text says now).  And
> > >that any probe chunk must be with an already acknowledged TSN.
> > >This will have the effect that any data along with the TSN will be
> > >discarded (and could be bogus), the receiver will be forced to
> > >SACK the duplicate TSN immediately, and new data will not flow.
> > >
> > >Comments?
> > ...snip...
> >
> >
> > _______________________________________________
> > tsvwg mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
> 
> --
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [e-mail]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)

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