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

Sourabh Ladha (EED) wrote:

>Hi Randall,
>
>Thanks for the clarification. My comments inline.
>
>  
>
>>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...
>>    
>>
>
>
>OK I see the picture. The main confusion started from point A2 which states:
>"When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding." coupled with F5 which only allowed congestion control to kick in if the "abondoning" decision was made on a retransmission decision.
>
>What may have been mentioned was that if the CumTSNpoint < Advanced.Peer.Ack.Point then all the congestion control mechanisms when needed MUST be applied (or, are still applicable) for the chunks lying between these two points. 
>
>
>  
>
>>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.. 
>>    
>>
>
>It may very well not be. Timestamps (12 bytes) and other options for TCP have been debataed a lot about adding overheads. But again I am not an expert in this, so if others think that this overhead is permissible then maybe we can go by it.
>

Well, I know that FreeBSD and Linux have timestamps on
by default in TCP.. so you always see this extra "12 bytes" in the
the releases I played with :-0

>
>  
>
>>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 may say that will be a feasible solution, but this per RTT rule should be relaxed if the FORWARD TSN is updating the "NewCumTSN" point reported in the last FORWARD TSN . To be clear this per RTT rule (if adopted at all) should only be for duplicate FORWARD TSNs.  
>
>And this scheme may add some state at the sender?
>
>  
>

Yeah, we would have to tweak the wording.. but I tend to agree
with Brian on this.. and maybe we should wait and hear what others
say...

>  
>
>>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...
>>    
>>
>
>I meant this.
>
>
>  
>
>>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... 
>>    
>>
>
>Not necessarily an RTT time. It can be less than that.
>  
>
But you don't send the FWD-TSN until you would normally
send a retransmission.. abandoning something does NOT mean you
send a FWD-TSN.. so you

A> abandon the TSN.

B>  At some later time, where you would do the retrans, you send
      the fwd-tsn...

The two are seperate events... and so you end up waiting until 4 strikes
or a T-O. I guess you could get 4 strikes in less than a RTT .. this is 
true.. but
at least 1/2 of the RTT must have passed.. aka you had to get the SACK's 
back
to strike the chunk... this is a real corner case in my opinion...

>  
>
>>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...
>>    
>>
>
>
>Well yes maybe a corner case for example consider  a sender had retransmitted a chunk (the original transmit being lost). And then abandoned it immediately. Lets assume that the retransmitted chunk reached after the FW-TSN (which can very well be considering multihomed endpoints and retransmission to the alternate). Then the reciever will generate a "fake" dup-tsn report. And blanton-allman's draft will be happy with the dup-tsn report and declare that retransmission spurious. Again I may agree that this is a corner case.
>

So now you are doing 1 retransmission and a abandon chunk. Again.. the 
sender still has the
information and can KNOW that it abandoned the chunk and you are still 
in a corner
case... since  you do

----TSN(111)---->XlostX
<4 strikes or T-O aka at LEAST 1/2 RTT + some amount>
----TSN(111)----->Retran--->
"mark for abandon 111"
<T-O aka at LEAST 1 RTO even greater than a RTT>
------FWD-TSN(111)--------->

Now in the above, where is the duplicate... the only way this would
happen is if the retransmission gets held a full RTO the FWD-TSN arrives
and then the retran arrives... this is IMO an even further strech than your
first example..

>
>
>  
>
>>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 comment had nothing to do with previous discussions on PR-SCTP. My comments about being aggressive were only linked to point (i) which I think you have now clarified. 
>  
>

I was wondering if you were not back addressing (i) so this
comment is a non-issue with the F5) clearification...

R

>
>Thanks,
>Sourabh
>
>_______________________________________________
>tsvwg mailing list
>tsvwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
>  
>

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