Subject: [Tsvwg] Re: A question on two methods of Fast Retransmit

From: Randall Stewart <[email-masked]>
Date: Mon, 23 May 2005 10:40:32 -0400

Greetings:

Mark, Vern and I have had a recent discussion on
SCTP's 4 missing reports to do a fast retransmit
vesus 3 missing reports in TCP... I think the
conclusion we have reached is that we really should
have done SCTP's FR algorithm the same as TCP.. aka
3 missing reports..

So..  thinking about this.. we probably should
add it to the implementors guide and correct this to
  be as Mark says... and yes I am overdue in getting
the "last 2 items" into the impelmentors guide :-9

I have some time this week.. so hopefully I will
get the other two items (per Minn) and this one.. and
we can get that in for last call..

Comments???

R

Randall Stewart wrote:
> MarK
> Comments below...
> 
> Mark Allman wrote:
> 
>> Randall-
>>
>> I can explain the TCP cases.  I am not sure I remember or ever knew why
>> SCTP uses the constant it uses.
>>
>> To trip FR in TCP takes 3 or 4 *duplicate* ACKs.  Just for the sake of
>> simplicity, say we're doing delayed ACKs and ACKing the even numbered
>> packets.  So, the cases look like this...
>>
>> Case #1
>> -------
>>
>> This is the receiver's behavior after receiving packets up to 56 in
>> order (58 being pulled out of the air) and we'll assume that packet 60
>> is lost:
>>
>>   packet 57 arrives, in order, delay ACK
>>   packet 58 arrives, in order, ACK 59 (next expected)
>>   packet 59 arrives, in order, delay ACK
>>   packet 61 arrives, trigger ACK for packet 60 (next expected)
>>     if using SACK packet 61 will be SACKed
>>   packet 61 arrives, trigger ACK for packet 60
>>     (maybe SACK for 60-61)
>>   packet 62 arrives, trigger ACK for packet 60
>>     (maybe SACK for 60-62)
>>   packet 61 arrives, trigger ACK for packet 60
> 
> You mean 63?
> 
>>     (maybe SACK for 60-61)
> 
> 
> So the above would be something like this for
> SCTP:
> 
> --------59---------->
> --------61---------->
> <----SACK(ca-59, 61-61)
> Cnt=1
> --------62---------->
> <----SACK(ca-59, 61-62)
> Cnt=2
> --------63---------->
> <----SACK(ca-59, 61-63)
> Cnt=3
> --------64---------->
> <----SACK(ca-59, 61-64)
> Cnt=4
> FR happens----60------>
> 
> 
>>
>> So, to trip FR we send 4 ACKs with the same ACK number - and they
>> correspond to 4 "missing reports", as well.
>>
>> Case #2
>> -------
>>
>> Rather than losing 60, assume 59 is lost.
>>
>>   packet 57 arrives, in order, delay ACK
>>   packet 58 arrives, in order, ACK 59 (next expected)
>>   packet 60 arrives, trigger ACK for packet 59 (next expected)
>>     if using SACK packet 60 will be SACKed
>>   packet 61 arrives, trigger ACK for packet 59
>>     (maybe SACK for 60-61)
>>   packet 62 arrives, trigger ACK for packet 59
>>     (maybe SACK for 60-62)
>>
> 
> And SCTP's case would be:
> -------58------->
> <---SACK(ca=58)
> -------60------->
> <----SACK(ca=58, 60-60)
> Cnt=1
> -------61------->
> <----SACK(ca=58, 60-61)
> Cnt=2
> -------62------->
> <----SACK(ca=58, 60-62)
> Cnt=3
> -------63------->
> <----SACK(ca=58, 60-63)
> Cnt=4
> FR happens ----60-------->
> 
> 
> So in both cases SCTP waits one extra packet to FR...
> 
> 
>> So, in this case we trip FR on 4 ACKs with the same ACK number but they
>> only correspond to 3 "missing reports".
>>
>>
>> The key is because of the delayed ACK in the first case the first
>> "missing report" changes the cumulative ACK point because there is an
>> ACK currently being delayed.  In the second case there is no ACK being
>> delayed and so the first missing report holds the ACK point constant.
>>
>> I am not sure this is a "corner case".  I think each case is probably
>> just as likely as the other.  It just depends on where the loss hits.
>>
>> IMO, case #2 is the best path.  But, there isn't really a way to
>> disambiguate things in non-SACK TCP.  In SCTP, since SACK is Just There,
>> I think you can just say 3 "missing reports" and leave it at that.  That
>> seems much cleaner to me.  (And, I think it would be nice to say this
>> for SACK TCP, as well.)
>>
>> Does that help?
> 
> 
> Yep... I think basically Paul is correct.. we got the wording
> wrong ... and it shoudl be 3 missing reports..
> 
> Vern??
> 
> R
> 
>>
>> allman
>>
>>
>>
> 
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

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