Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-00.txt

From: [email-masked]
Date: Wed, 16 May 2001 16:49:44 +0300

Hi Randall!

> >         Hi!
> > 
> >         One comment:
> > 
> >         - Section 4.5.2, S1): It seems that the outstanding 
> chunks are all
> > the chunks whose TSN is older than the Cumulative TSN 
> ACK... What about the
> > ones already acknowledged by a "Gap Ack Block" in a SACK? are they
> > considered outstanding as well?
> > 
> 
> I think you MUST consider them outstanding.. since at any time the
> peer may REVOKE the SACK. Thus you MUST wait until the CUM-TSN passes
> the TSN value before allowing your upper layer to send/queue 
> more data.

	So, do you really mean that the TSNs acknowledged by Gap Ack Blocks
are considered to be outstanding? I thought you shouldn't erase them (just
in case the peer revokes them, as you said), but you shouldn't count them as
being outstanding for the congestion algorithm...

	Section 1.4 of RFC2960 says:

   o  Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
      DATA chunk) that has been sent by the endpoint but for which it
      has not yet received an acknowledgement.

	I have always understood this as those TSNs acknowledged inside gaps
are not outstanding anymore... Am I wrong?

	BR Iván Arias Rodríguez

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 09:11:10 -0500

> being outstanding for the congestion algorithm...

You do NOT erase them.. the sender must hold them. The wording I have
put in the srwnd portion says you count as outstanding anything
that the CUM-ACK has NOT moved past. Yes for CC purposes you don't
count these has outstanding.. but we are talking about something
different here. 

You would need to:

A) put in very complex rules about deliverability.
B) be assuming the data got delivered and read by the app.

Has it is, you are never really assured of B above even when
the cum-ack moves past it. Remember we are trying to prevent
the STREAM receiver from being overrun here... not the CC algorithms.

So I do not think it is good to change this.. if the CUM-ACK has
NOT moved past the Stream/Seq it is still considered outstanding
not to CC but to the srwnd portion of the code..

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 09:35:40 -0500

I think you and are are not communicating very
well..

> are considered to be outstanding? I thought you shouldn't erase them (just

You are missing my point... FOR CONGESTION CONTROL the chunks ARE
NOT CONSIDERED OUTSTANDING!!!! PERIOD!!! 

For the SRWND purposes the "OUTSTANDING" is not the same thing
has the congestion control algorithms. Maybe this is a BAD
choice in wording... hmmm I will have to think up another
term for this condition..

For SRWND limiting we want the CUM-ACK to have moved past
the TSN before we add back the size to what the stream
can have outstanding...

R