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

["Randall R. Stewart (home)" <[e-mail]>]

Sourabh Ladha (EED) 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.
>  
>

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

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

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

R



>
>Thanks
>-Sourabh
>
>
>
>
>  
>
>>From: "Peterson, Jon" <[e-mail]>
>>To: [e-mail]
>>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: [e-mail]
>>X-BeenThere: [e-mail]
>>X-Mailman-Version: 2.0.12
>>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
>>        <mailto:[e-mail]?subject=unsubscribe>
>>List-Id: Transport Area Working Group <tsvwg.ietf.org>
>>List-Post: <mailto:[e-mail]>
>>List-Help: <mailto:[e-mail]?subject=help>
>>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
>>        <mailto:[e-mail]?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
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/tsvwg
>>    
>>
>
>_______________________________________________
>tsvwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
>  
>



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