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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

A router that goes down and queues pending outgoing ICMPs, then emits
them when up, could win the lottery by design.

The question is whether it matters for your algorithm. If the connection
didn't proceed anyway and this is still a useful signal, then say so.

If the connection could proceed on other paths, and as a result the
sequence numbers would need to wrap and be in-window to work, then the
probability of this happening depends on the width of the window - which
has been getting larger, and could make such a lottery more likely than
you're planning for. Again, does it matter?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkqpcJIACgkQE5f5cImnZrs9oACePJC7XzJbjKBIpQsOX4o4cjAI
knoAn06lbo0bzlPj+rS/bDjIccSEbbko
=ravf
-----END PGP SIGNATURE-----