Date: Tue, 31 May 2011 10:09:25 +0100 From: "Scheffenegger, Richard" <rs@netapp.com> To: <freebsd-net@freebsd.org> Subject: RFC3517bis rescue retransmission Message-ID: <5FDC413D5FA246468C200652D63E627A0E99C8C6@LDCMVEXC1-PRD.hq.netapp.com>
next in thread | raw e-mail | index | archive | help
Hi, RFC3517bis has added a provision to fix a special corner case of SACK loss recovery. Under certain circumstances (end of stream), TCP SACK can be much less effective in loss recovery than TCP NewReno. For a history of this corner case, please see https://datatracker.ietf.org/doc/draft-scheffenegger-tcpm-sack-loss-reco very/ http://tools.ietf.org/html/draft-nishida-tcpm-rescue-retransmission-00 and the final agreed algorithm: http://www.ietf.org/mail-archive/web/tcpm/current/msg06518.html (to be included in 3517bis) However, the final version would not work well, if that first retransmitted segment is also lost (unfortunately, the first retransmitted segment has the highest probability to get lost again...). I would like to get feedback on the following idea: Whenever the socket does not hold any additional data, or no new segments can be sent beyond snd.max: min(so->so_snd.sb_cc, sendwin) - off =3D=3D 0 and a hole in the scoreboard shrinks (or is removed), set a flag (ie. Sackhint.hole_shrunk =3D 1) in sack_do_ack. In sack_output, if all the holes were transmitted once (the entire scoreboard is traversed, without finding a new hole to send), and the above conditions (no new data elegible to send, and flag is set, and rescue "hole" does not exist) hole, add one "rescue" hole of size mss, starting at snd.nxt-mss to the scoreboard, adjust the retransmission trigger values (from snd.nxt to snd.nxt-1)... This would keep that change co-located with the SACK code, the rescue retransmission would be treated like any other hole during SACK recovery processing. Also, this would be compatible with lost retransmission detection. When the receive buffer is full, or the sender does not have any new data to send, the sender can still track if the rescue retransmission made it. If it does, by adjusting the retransmission trigger, any still pending holes would be retransmitted (pipe allowing...) again. If the receiver buffer was full, because a lost first retransmission cause a head-of-line blocking, this would unlock the receive window as snd.una advances. Any comments? Richard Scheffenegger
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5FDC413D5FA246468C200652D63E627A0E99C8C6>