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

[Gorry Fairhurst <[e-mail]>]

On 24/03/2010 06:32, Mark Allman wrote:
>
>> 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
>
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