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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Mar 2010 15:15:38 -0700

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 24 Mar 2010 09:32:05 -0400

> 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.

I wasn't in the meeting so perhaps I don't have the right context here.
But, I guess I don't quite see the concern.  Presumably these methods
actually help the cause---not hurt it.

I.e., if I send a SYN-with-ECN and then spuriously RTO because I am
traversing a long path I will send a SYN-w/o-ECN.  When I see a SYN-ACK
I'll be able to tell which SYN triggered it and therefore do the right
thing (i.e., get an RTT sample, tell if the retransmit was likely
spurious or not, etc.).

Am I missing something here?

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 24 Mar 2010 07:53:02 -0700

> Am I missing something here?
Thanks Mark,

I wasn't saying the method broke ECN negotiation, and other things that 
work in this way. I wanted to be sure that implementors would realise 
that this MUST be handled correctly, and avoid finding that people 
over-focused on short paths, without realising that the 1st RTO expiry 
on a 1-3 sec path did NOT necessarily indicate a path problem.

I could imagine a (bad) implementation that sent a SYN+ECN and the RTO 
expired, it then concluded that ECN (or whatever) wasn't supported, 
cleared the internal flag that indicates ECN would be used, and then 
sends a simple SYN.

Whereas, what you outline seems good practice and I think says that the 
sender should take the received SYN-ACK+ECN as indication that ECN can 
be used (even if the sender knows the last SYN did not include this 
option, and the next SYN-ACK does not).

I think this detail was not clear when ECN, QuickStart, etc was 
standardised. If this approach was called-out in the document this would 
seem to be good.

Gorry

---

From: Mark Allman <[email-masked]>
Date: Wed, 24 Mar 2010 10:58:33 -0400

> standardised.

More than likely because spurious retransmissions after 3sec are pretty
rare. 

> If this approach was called-out in the document this
> would seem to be good.

Your point is fair and I have made a note to include some words in a
next revision of the document (assuming the WG thinks its a reasonable
thing to work on in the first place).

allman

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 24 Mar 2010 15:18:29 +0000

Am 24.03.2010 um 07:58 schrieb Mark Allman:

> (assuming the WG thinks its a reasonable

YES :-)

> 
> allman
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm