Subject: [Tsvwg] Re: WGLC on draft-ietf-tsvwg-prsctp-00

From: "Sourabh Ladha (EED)" <[email-masked]>
Date: Thu, 26 Jun 2003 14:22:21 +0200

Since the draft is for last call, I would be glad to hear comments/clarifications on the following:

(i) Consider a scenario, where a chunk is marked "abandoned" by the sender (due to timed reliability or any other newcoming service definition). Consider that the abandoned message was actually lost and that after having marked "abandoned", the sender recieved the 4th missing report for this chunk in a SACK (If sticking to the timed reliability service: if the lifetime expires and is evaluated before the 4th missing report comes in). For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT react (i.e. reduce its cwnd and so on) to this 4th missing report. Note that both reliable and partially reliable messages can be carried in the same association. Isnt congestion a property of the network. If so, then shouldnt the PR-SCTP sender react to this 4th missing report of the abandoned chunk by reducing congestion control state, however it does not need to do a fast retransmit because the data is useless anyway. The draft may point out, that if this is the case, th!
 en it is being aggressive. This may not be a corner case.

(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is followed for every incoming SACK. Consider the scenario:

A    1       B
-----lost	   
------2------>
     .	   	
     .	    	
     .	   	
------10----->
		    	
   dup ack 1   
<-------------
At this point of time A abandons 1. 

From now on every dup-ack that comes in may generate a FW-TSN (with the same cum TSN value of 2). 

So in effect the sender:
(a) If the app still has data to send, reduce the effective payload by bundling repetative FW-TSN chunks in the packet.
(b) If the app has nothing to send currently, then either: 
	(i) it "MAY" delay the FW-TSN 
	(ii) or it may do a FW-TSN implosion if it is not delayed.

Either way the issue is why to send the same FW-TSN over and over again? For large congestion windows and high RTT paths this may cause trouble. 

(iii) A forward TSN when recieved, updates and normally advances the cum-ACK point. Now, if the chunks prior to that which were "abandoned" by the sender are now recieved (they may have gone through delay or reordering or some other cause), the reciever generates a "fake" dup-tsn report for each of them. This is because the data chunk TSN recieved is behind the current cum-TSN point at the reciever. Not only this adds extra SACK traffic (carrying fake dup-tsn reports which are of no use to the sender) but may also cause problems to certain algorithms (like blanton&allman's "Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not a new transport protocol, it is an extension which very well resides with RFC 2960. So either PR-SCTP reciever may be made capable of not generating these "fake" dup-tsns or the other drafts (proposed or future) which use dup-tsn reports should make an attempt to mention if they work well even when PR-SCTP is enabled in an assoction.

(iv) This is sort of a tangent. But, seems like there can be services which remain in the framework of PR-SCTP but are aggressive and can motivate unfriendly applications. I think, the draft dosent stress on the REQUIREMENT for service definitions to be standardized within the IETF. 

Thanks
-Sourabh

>From: "Peterson, Jon" <[email-masked]>
>To: [email-masked]
>Date: Sun, 22 Jun 2003 16:21:54 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Subject: [Tsvwg] WGLC  on draft-ietf-tsvwg-prsctp-00
>Sender: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Id: Transport Area Working Group <tsvwg.ietf.org>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
>         <mailto:[email-masked]?subject=subscribe>
>X-OriginalArrivalTime: 22 Jun 2003 21:25:48.0590 (UTC) 
>FILETIME=[D95CDCE0:01C33904]
>
>
>The chairs would like to initate a two week working group last call for the
>PR SCTP draft commencing Monday 6/23/2003. Please direct all relevant
>comments to this list.
>
>Thanks!
>
>Jon Peterson
>NeuStar, Inc.
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Thu, 26 Jun 2003 08:37:13 -0500

> en it is being aggressive. This may not be a corner case.

We added for the above case:

F5) If a decision to "abandon" a chunk is made based on a
      retransmission decision (e.g T3-Timeout or Fast Retransmit) the
      appropriate congestion adjustment as specified in RFC2960 MUST be
      made before any FORWARD TSN chunk is sent.

But I can see it may not have been clear  enough. Maybe it should be 
tightened up a bit ..

I think the main issue that people forget when looking at PR-SCTP is 
that just because the sender
decides to abandon a chunk does NOT mean that all records of the chunk 
are dropped... in fact
the sender MUST maintain some basic state on the chunk until the 
Cumulative-Ack point passes
the chunk being abandonded... you don't have to maintain the data.. but 
you DO have to maintain
things such as the TSN and strike count etc.

Maybe F5) should be reworded:

F5) If a decision to "abandon" a chunk is made, no matter how such decision
       is made, the appropriate congestion adjustment MUST be made as 
specified in RFC2960
       if the chunk later would have been marked for retransmission 
(e.g. T3-Timeout or
       Fast Retransmit).

I will add the above change to the list of WG-Last call changes if no 
one objects...

>(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is followed for every incoming SACK. Consider the scenario:

The reason you must send it until you get a SACK is that you don't know 
if the
peer received it. A Fwd-TSN can be lost just like a data chunk.... A 
fwd-TSN is
relatively small (smaller than a SACK).. I don't see how this is a big 
issue.. however
I suppose we could modify the algorithm a bit and add a rule that states:

No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response
to a SACK, the sender MUST NOT send more than one FWD-TSN every RTT.

This would then eliminate (ii) as an issue no matter how many SACK's the 
peer
sends at you ...

So how about changing F2) to state:

  F2) The data sender SHOULD always attempt to bundle an outgoing
      FORWARD TSN with outbound DATA chunks for efficiency.

      A sender MAY even choose to delay the sending of the FORWARD TSN
      in the hope of bundling it with an outbound DATA chunk. But no matter
      if a sender delays a FORWARD TSN or sends one in response to a SACK,
      a sender MUST NOT have more than one FORWARD TSN in flight per
      round trip time.

>(iii) A forward TSN when recieved, updates and normally advances the cum-ACK point. Now, if the chunks prior to that which were "abandoned" by the sender are now recieved (they may have gone through…

I am missing something here.. what do you mean by 'chunks prior to theat 
which were "abandonded"'

Do you mean you abandonded it and then later it arrived...

or

Do you mean you abandoned a chunk 10 and then 8 and 9 arrived?

I think the first definition.. if I read your concern correctly .. is 
what you mean..

I.e. I send a fwd-tsn(10)------->

and then some time later TSN-10 arrives.

First of all I think this is a real corner case and does not happen that 
often... basically the
network must reorder and hold a packet for longer than the RTT time... 
Yes I realize
routing loops and such during convergance may cause this.. but it is a 
rare event. So
I don't see how one extra dup report that is very rare is going cause an 
issue... now
on to using the dup report.. as I said above, the sender MUST keep track of
things until the cum-ack passes by.... Now looking specifically at 
blanton/allman
it says something to the effect that "the sender MUST detect if the 
duplicate was
retransmitted and if not (i.e. the network duplicated it) stop using the 
algorithm"... now
this wording was made for network duplications.. but it makes me think 
of a couple
of things:

1) In order to do the above, the cum-ack must NOT have passed the TSN.. 
otherwise
    the sender would have no way to do the above.... which means you 
know you
    skipped it on the sender side... see my above statements on state :->

2) The statement from blanton/allman would give the impression that the 
FWD'd chunk was a
    network duplicate thus disabling the algorithm..

So I think that:

a) the blanton/allman document already covers it
and
b) Once the cum-ack is past a point the blanton-allman document will have
    little effect to PR-SCTP or just plain SCTP...

>(iv) This is sort of a tangent. But, seems like there can be services which remain in the framework of PR-SCTP but are aggressive and can motivate unfriendly applications. I think, the draft dosent…
You are  off on a tangent here IMO :> ... Please explain to me how 
PR-SCTP can motivate
aggressive behavior? We have had long converstations on this list about 
this.. and a lot of
off-line conversations as well with Mark Allman.. We have not been able 
to come
up with a scenario for this.. I believe at one point (off-line) Phil 
Conrad offered to
do some simulation work on this very issue.. and we could not come up with
a valid scenario.. the cwnd is being obeyed by the underlying SCTP 
stack... the
rwnd as well.. how does PR-SCTP make the sender more aggressive?

I would contend that PR-SCTP does just the opposite.. in times of 
congestion it reduces
network traffic by taking data OFF the network... can you please specify 
something besides
a vague statement? If you can come up with a valid scenario I am sure 
between Phil
and I, we could do a simulation or study  to prove or dis-prove your 
contention of aggressiveness...

As to the service definition.. maybe you could connect this thought to 
the aggressive claim
above? How would when a decision to abandon being made change the 
aggressiveness of
PR-SCTP.. please consider also the clearication to F5) above .. I would 
like to know
if this is possible that a definition could influence the on-wire 
performance.. I don't
see how.. but as I said.. I would be glad to try to find through 
simulation or test such
a weakness...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jun 2003 08:42:14 -0600

Randall,

On Thu, 26 Jun 2003, Randall Stewart wrote:

> >Since the draft is for last call, I would be glad to hear
> >comments/clarifications on the following:
> >
> >(i) Consider a scenario, where a chunk is marked "abandoned" by the sender
> >(due to timed reliability or any other newcoming service definition).
> >Consider that the abandoned message was actually lost and that after having
> >marked "abandoned", the sender recieved the 4th missing report for this
> >chunk in a SACK (If sticking to the timed reliability service: if the
> >lifetime expires and is evaluated before the 4th missing report comes in).
> >For a PR-SCTP sender, the chunk is no longer outstanding and it does NOT
> >react (i.e. reduce its cwnd and so on) to this 4th missing report. Note
> >that both reliable and partially reliable messages can be carried in the
> >same association. Isnt congestion a property of the network. If so, then
> >shouldnt the PR-SCTP sender react to this 4th missing report of the
> >abandoned chunk by reducing congestion control state, however it does not
> >need to do a fast retransmit because the data is useless anyway. The draft
> >may point out, that if this is the case, th!  en it is being aggressive.
> >This may not be a corner case.
> >  
> >
> 
> I think the main issue that people forget when looking at PR-SCTP is that
> just because the sender decides to abandon a chunk does NOT mean that all
> records of the chunk are dropped... in fact the sender MUST maintain some
> basic state on the chunk until the Cumulative-Ack point passes the chunk
> being abandonded... you don't have to maintain the data.. but you DO have to
> maintain things such as the TSN and strike count etc.
> 
>     is made, the appropriate congestion adjustment MUST be made as specified
>     in RFC2960 if the chunk later would have been marked for retransmission
>     (e.g. T3-Timeout or Fast Retransmit).
> 
> 
> I will add the above change to the list of WG-Last call changes if no one
> objects...

The above sounds fine to me.

> 
> 
> 
> >
> >(ii) A Forward TSN (FW-TSN) chunk generation algorithm (section 3.5) is
> >followed for every incoming SACK. Consider the scenario:
> >
> >A    1       B
> >-----lost	   
> >------2------>
> >     .	   	
> >     .	    	
> >     .	   	
> >------10----->
> >		    	
> >   dup ack 1   
> ><-------------
> >(a) If the app still has data to send, reduce the effective payload by
> >    bundling repetative FW-TSN chunks in the packet.

> >Either way the issue is why to send the same FW-TSN over and over again?
> >For large congestion windows and high RTT paths this may cause trouble. 
> >
> 
> The reason you must send it until you get a SACK is that you don't know if
> the peer received it. A Fwd-TSN can be lost just like a data chunk.... A
> fwd-TSN is relatively small (smaller than a SACK).. I don't see how this is
> a big issue.. however I suppose we could modify the algorithm a bit and add
> a rule that states:
> 
> No matter if the sender does a delayed FWD-TSN or a FWD-TSN in response to a
> SACK, the sender MUST NOT send more than one FWD-TSN every RTT.
> 
> peer sends at you ...

I disagree.  The receiver is allowed to have more than one SACK in flight
per RTT, why is the sender not allowed to have one FORWARD TSN per SACK?

If the FORWARD TSNs cause problems, then so will the SACKs alone.

If there is a problem here, it is with the SACKs.

> 
> 
> >
> >
> >(iii) A forward TSN when recieved, updates and normally advances the
> >cum-ACK point. Now, if the chunks prior to that which were "abandoned" by
> >the sender are now recieved (they may have gone through delay or reordering
> >or some other cause), the reciever generates a "fake" dup-tsn report for
> >each of them. This is because the data chunk TSN recieved is behind the
> >current cum-TSN point at the reciever. Not only this adds extra SACK
> >traffic (carrying fake dup-tsn reports which are of no use to the sender)
> >but may also cause problems to certain algorithms (like blanton&allman's
> >"Using dup-tsn to detect spurious retransmissions" ). Since PR-SCTP is not
> >a new transport protocol, it is an extension which very well resides with
> >RFC 2960. So either PR-SCTP reciever may be made capable of not generating
> >these "fake" dup-tsns or the other drafts (proposed or future) which use
> >dup-tsn reports should make an attempt to mention if they work well even
> >when PR-SCTP is enabled in an assoction.
> >  
> >
> 
> often... basically the network must reorder and hold a packet for longer
> than the RTT time...  Yes I realize routing loops and such during
> convergance may cause this.. but it is a rare event. So I don't see how one
> extra dup report that is very rare is going cause an issue... now on to
> using the dup report.. as I said above, the sender MUST keep track of things
> until the cum-ack passes by.... Now looking specifically at blanton/allman
> duplicate was retransmitted and if not (i.e. the network duplicated it) stop
> using the algorithm"... now this wording was made for network duplications..
> but it makes me think of a couple of things:
> 
> otherwise the sender would have no way to do the above.... which means you
> know you skipped it on the sender side... see my above statements on state
> :->
> 
> FWD'd chunk was a network duplicate thus disabling the algorithm..
> 
> So I think that:
> 

I think is is the responsibility of these other drafts to consider
PR-SCTP, rather than visa versa.

> 
> 
> >
> >(iv) This is sort of a tangent. But, seems like there can be services which
> >remain in the framework of PR-SCTP but are aggressive and can motivate
> >unfriendly applications. I think, the draft dosent stress on the
> >REQUIREMENT for service definitions to be standardized within the IETF. 
> >  
> >
> You are  off on a tangent here IMO :> ... Please explain to me how PR-SCTP
> can motivate aggressive behavior? We have had long converstations on this
> list about this.. and a lot of off-line conversations as well with Mark
> Allman.. We have not been able to come up with a scenario for this.. I
> believe at one point (off-line) Phil Conrad offered to do some simulation
> work on this very issue.. and we could not come up with a valid scenario..
> the cwnd is being obeyed by the underlying SCTP stack... the rwnd as well..
> how does PR-SCTP make the sender more aggressive?
> 
> I would contend that PR-SCTP does just the opposite.. in times of congestion
> it reduces network traffic by taking data OFF the network... can you please
> specify something besides a vague statement? If you can come up with a valid
> scenario I am sure between Phil and I, we could do a simulation or study  to
> prove or dis-prove your contention of aggressiveness...
> 
> As to the service definition.. maybe you could connect this thought to the
> aggressive claim above? How would when a decision to abandon being made
> change the aggressiveness of PR-SCTP.. please consider also the clearication
> to F5) above .. I would like to know if this is possible that a definition
> could influence the on-wire performance.. I don't see how.. but as I said..
> I would be glad to try to find through simulation or test such a weakness...

I think we had this discussion already and came to concensus that this
discussion has much greater scope that PR-SCTP and PR-SCTP should not be
held up waiting for this greater discussion to occur or conclude.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Thu, 26 Jun 2003 09:57:35 -0500

Brian F. G. Bidulock wrote:

>>>From now on every dup-ack that comes in may generate a FW-TSN (with the
>>    
>>
>>>same cum TSN value of 2). 
>>>
>>>So in effect the sender:

That is a good point... the FWD-TSN's are generally even
smaller than the SACKs...

Delaying the FWD-TSN could in theory cause held data at
the reciever to remain there longer... its definetly a trade-off..

What do others think? worth worrying about... or better left alone??

>PR-SCTP, rather than visa versa.
Yeah, its really kind of hard for a RFC/draft to figure out what
things will be written in the future :> If we could do that, hey we
could get rich in the stock market :-D

>held up waiting for this greater discussion to occur or conclude.
That is my thought as well.. unless Sourabh has a further clearification to
add to this...

R

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 26 Jun 2003 15:59:24 -0400 (EDT)

> What do others think? worth worrying about... or better left alone??

I think it is better left alone. I don't see a problem, but delaying
FWD-TSN would be a problem.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0