From owner-freebsd-net@FreeBSD.ORG Tue May 31 09:10:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F10A1065674 for ; Tue, 31 May 2011 09:10:09 +0000 (UTC) (envelope-from rs@netapp.com) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE0B8FC16 for ; Tue, 31 May 2011 09:10:08 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.65,296,1304319600"; d="scan'208,217";a="257734830" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 May 2011 02:10:07 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p4V9A7b8019923 for ; Tue, 31 May 2011 02:10:07 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 May 2011 10:10:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 May 2011 10:09:25 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0E99C8C6@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3517bis rescue retransmission Thread-Index: Acwfcm/658ChV5N9Q3icKGlkvvF3Og== From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 31 May 2011 09:10:07.0034 (UTC) FILETIME=[88E4F1A0:01CC1F72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RFC3517bis rescue retransmission X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 09:10:09 -0000 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