[tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 23 March 2010 22:15 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3AD23A6BF4 for <tcpm@core3.amsl.com>; Tue, 23 Mar 2010 15:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.13
X-Spam-Level: *
X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3OnThlLR6om for <tcpm@core3.amsl.com>; Tue, 23 Mar 2010 15:15:52 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 16A153A6CE8 for <tcpm@ietf.org>; Tue, 23 Mar 2010 15:15:37 -0700 (PDT)
Received: from dhcp-wireless-open-abg-27-155.meeting.ietf.org ([IPv6:2001:df8:0:24:21e:c2ff:febe:4c73]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id o2NMFd9T006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 22:15:40 GMT
Message-ID: <4BA93D8A.8080508@erg.abdn.ac.uk>
Date: Tue, 23 Mar 2010 15:15:38 -0700
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: tcpm@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Subject: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2010 22:15:53 -0000

The point I raised in TCPM today was that there are likely other 
side-effects from a SYN RTO expiry. I saw appendix describes a measure 
to protect from unwanted side effects when the RTO is less than 3 secs. 
I suspect reducing the SYN over a longer path, such that there is a SYN 
retransmission can also have other
side effects.

One is noted that IW is not to be effected when the first RTO expires.

I suggest there should be a more general change to the draft so that the 
TCP sender SHOULD NOT modify startup parameters when the RTO expires 
within "6" seconds (or whatever period you think applies in current use.

My rationale is that there are transport methods that use retransmission 
of a SYN as the indication that there may be something problematic with 
the path, and then modify their behaviour.

For example, ECN-capable systems may disable the use of ECN on SYN 
retransmission. RFC 3168 says: "A host that receives no reply to an 
ECN-setup SYN within the normal SYN retransmission timeout interval MAY 
resend the SYN and any subsequent SYN retransmissions with CWR and ECE 
cleared. To overcome normal packet loss that results in the original SYN 
being lost, the originating host may retransmit one or more ECN-setup 
SYN packets before giving up and retransmitting the SYN with the CWR and 
ECE bits cleared."

An experimental use is Quickstart (s 4.7.2) where retransmission may use 
a similar method: "packet containing the Quick-Start Request, then the 
TCP sender SHOULD resend the SYN or SYN/ACK packet without the 
Quick-Start Request".

Could there be similar implications for IPv6/IPv4 probing?

Gorry