[tcpm] Detect Lost Retransmit mit SACK
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[tcpm] Detect Lost Retransmit mit SACK
Hi,
Scheffenegger, Richard schrieb:
> Thanks for your comment; unfortunately, I'm not supposed to get
> inspiration from GPL'ed code :)
>
>
> Do you know which kernel versions feature this? I've checked 2.6.16 and
> 2.6.18 (commercial distributions), but none of the most recent ones...
At least 2.6.24 (Ubuntu 8.04 LTS) and newer have this.
>
> FACK as described here
> http://www.psc.edu/networking/papers/FACKnotes/current/
> seems to be a sender-only algorithm; Thus if the receiver is
> implementing
> SACK, the sender should be able to use it, right?
As far as I remember the advantage of FACK for detecting lost
retransmissions is, that you can be sure that after invoking
"Fast Retransmit" you retransmitted all holes up to RecoveryPoint
before sending any new data. Now you can use any ACK containing
a SACK block above RecoveryPoint for an indication of a
lost retransmission. But note, that FACK has serious problems
with reordering.
In my opinion SACK-TCP you would need to track a lot more.
Thinking of it, maybe it would be enough to store highest seq
sent so-far for each retransmit. And then check this for incoming
SACKs individually for each retransmit. Might be still too expensive...
[Shortened E-mail]
>
> And with the last statement (fastretransmission finished) I referred
> To the point in time, when the sender has sent all segments being
> flagged
> By SACK to have been missing, before noticing (one RTT later) that
> another
> One might be missing; this might be a special case, though, as I assumed
> That retransmission would end prior to the receiver detecting the
> 2nd loss...
Don't forget that with SACK-TCP the TCP sender will mix retransmissions
and new segments all the time during recovery.
The interesting part is: How does the TCP sender detect, that a
retransmission might be missing? Simply checking against RecoveryPoint
would not work... Or only for the "first hole".
>
> I guess a time-flow diagram would help :)
Yes please!
Best regards,
Arnd Hannemann
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.