* (unknown)
@ 2010-12-21 10:35 Richard Scheffenegger
2010-12-21 10:42 ` Linux SACK - lost retransmission detection Richard Scheffenegger
0 siblings, 1 reply; 2+ messages in thread
From: Richard Scheffenegger @ 2010-12-21 10:35 UTC (permalink / raw)
To: netdev
Hi guys,
You may be interested in this draft I recently posted:
http://tools.ietf.org/html/draft-scheffenegger-tcpm-sack-loss-recovery-00
It addresses a minor nit-pick fix in the SACK specs, and is a sender-only modification.
Basically, with SACK a sender following RFC3517 will ignore partial ACKs as signal that some segments running up to the end-of-stream are lost. SACK will only recover "known" holes - which means that at least one segment after the lost segment has to be received (and the ACK/SACK for this has to get to the sender).
Under certain circumstances - when the sender is regularly limited in the amount of data to send, either by the application, network (cwnd) or receiver (rwnd), loss of the last segment before RecoveryPoint leads to avoidable RTOs - if the sender would use the partial ack (ACK without any SACK entries, but below RP / snd.max) also as loss indication just as NewReno does. In comparison, using NewReno (disabling SACK), one can get improved delivery latencies, as partial ACKs trigger a retransmission with NewReno.
For the public internet, I received reports by a major player indicating a shift between 0.1 and 0.8% from RTOs to fast retransmission (at a overall RTO vs. FastRetransmit ratio of ~60%)
For private LANs, which run different applications such as NFS and very often stall until one such transaction finishes, I can not provide solid data, but it appears that the impact is more pronounced - but the RTO/FR ratio there is typically only 20-40%.
Please let me know what you think about this change.
Richard Scheffenegger
--
GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern
E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail
^ permalink raw reply [flat|nested] 2+ messages in thread
* Linux SACK - lost retransmission detection
2010-12-21 10:35 (unknown) Richard Scheffenegger
@ 2010-12-21 10:42 ` Richard Scheffenegger
0 siblings, 0 replies; 2+ messages in thread
From: Richard Scheffenegger @ 2010-12-21 10:42 UTC (permalink / raw)
To: netdev
Hi,
One more, generic, question:
I found that Linux added SACK with kernel version 2.1.91, but I wasn’t able to track down when lost retransmission detection (LRD) was added. The only research paper I found which appears to describe approximately what linux does is from an Korean researcher, who claims to have not contributed any code to the linux kernel. Do you happen to have more pointers?
I’m currently looking into ways of how to make lost retransmissions detection work also at end-of-stream (alleviating RTOs even with small windows at least partially).
Best regards,
Richard
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-12-21 10:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-21 10:35 (unknown) Richard Scheffenegger
2010-12-21 10:42 ` Linux SACK - lost retransmission detection Richard Scheffenegger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).