Re: [tcpm] poll for adoption of long connectivity disruptions draft

[Pasi Sarolahti <[e-mail]>]

On Sep 9, 2009, at 6:42 AM, Alexander Zimmermann wrote:

>> * The title would benefit from some tweaking. Maybe its just a matter
>> of changing "Make" => "Making"
>
> Ok, we will change the title to "Making TCP more Robust to Long
> Connectivity
> Disruptions". I'm also fine with changing it to something completely
> different,
> are there any suggestions?

No. I think "Making TCP..." is just fine.

>>
>> * Section 4.2, algorithm: this is really a nit, but might want to
>> clarify in step (5) that if ICMP DU contains non-TCP header it should
>> be ignored, without affecting the algorithm (right?)
>
> In our algorithm we assume that the ICMP error message is passed
> up from the IP layer, for the corresponding connection.
> (See RFC 1122 Section 4.2.3.9 ). Ack, we will make this more clear.
> However, I think the fact that the ICMP message already got
> demultiplexed implies that the ICMP DU contains a TCP header,  
> otherwise
> we would "not see" this ICMP DU at this layer.

You are right, but I guess details might depend on implementation. And  
there might be possibilities for further optimization with non-TCP  
generated ICMPs, as per Joe's earlier mail.

>> * It would be interesting to have an accompanying technical report on
>> some (even preliminary) results on the performance improvements using
>> the algorithm. It would also be interesting to have some  
>> understanding
>> how often ICMP Destination unreachables actually arrive in case of a
>> real connectivity disruption in real world.
>
> Depends on what you mean with "real world" we have already presented
> some measurements with Linux routers, see the slides from the last
> IETF meetings. And the ICMP DU arrive surprisingly reliable.
> However, we did not test juniper or cisco yet...

Yep, the graphs in the meeting slides are nice. As an optional further  
step (if someone had the time) they could be wrapped with some  
explanatory text into a paper format to be used as a reference for  
people trying to assess the benefits.

Regarding "real world", I had something like today's 3G & WiFi  
networks in mind.

- Pasi