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

Hi Joe,

thanks for your remarks. As always, comments are inline...

Alex

Am 09.09.2009 um 00:49 schrieb Joe Touch:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Pasi Sarolahti wrote:
> ...
>> * 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?)
>
> It's not clear whether that is a feature or a bug.
>
> If you have TCP that's idle, and other packets from your host  
> traverse a
> path and generate ICMP DUs, your TCP could benefit from reacting. I
> didn't see anything in 1122 that would prevent that.

In my opinion the algorithm should only respond to ICMPs which can be  
demultiplexed to a specific connection (see e-mail reply to Pasi).  
Exploiting other ICMP DUs may be possible, as a future work, but I  
fear it may be dangerous and collide with policy routing etc. For  
instance I wouldn't be surprised if there are "creative" ISPs which  
route HTTP connections differently than SMTP connections.

>
> - --
>
> FWIW, this draft continues the erroneous assumption that ICMPs are  
> sent
> in a timely fashion. Routers aren't required to do this, and so the
> sequence number inside an ICMP should never be used as critical
> information. It'd be useful (if not important) to explain the impact  
> of
> this on the algorithm in the draft.

Ack that we should it explain more deeply. However I have to disagree  
with you: we explicitly allow routers to delay ICMPs, and try to  
benefit from those "delayed" ICMPs as long as those delayed ICMPs  
belong to the current RTO-induced loss recovery phase. Moreover, there  
are two important things to note:

1.) We check for an exact match of SND.UNA (no window etc.) with the  
sequence number included in the ICMP DU. What are the chances that a  
delayed ICMP matches SND.UNA, but not belonging to that RTO period  
arrives while this same TCP connection (ports and IPs match) is in  
timeout-based loss recovery? I say you better play lottery ;-)

2,) Even if such an very unlikely event ever occurs the impact of such  
an ICMP DU is obviously very low.

Partly this is explained in Section 4.3 in the paragraph about  
sequence number wraps. But we probably separately address the
special timing issues of ICMPs.

>
> Hie
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqm32wACgkQE5f5cImnZruZ6QCgmy/Op6oqLMTq8XFoNSMNki6p
> 3zwAnRxph15X2K6pRQV1voL2PqJ3qVwf
> =rPsC
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm