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

Brian F. G. Bidulock wrote:

>Randall,
>
>On Thu, 26 Jun 2003, Randall Stewart wrote:
>
>  
>
>>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...
>>    
>>
>
>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   
>>><-------------
>>>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.
>>    
>>
>
>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.
>  
>

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

>  
>
>>    
>>
>>>(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...
>>
>>    
>>
>
>I think is is the responsibility of these other drafts to consider
>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

>  
>
>>    
>>
>>>(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.
>  
>
That is my thought as well.. unless Sourabh has a further clearification to
add to this...

R

>--brian
>
>  
>

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg