Re: [tcpm] Congestion control in face of ICMP unreachable messages

Daniel Schaffrath wrote:
> 
...
>>     * ICMP operates on a different timescale than TCP.  It may take
>>       a router longer to decide that there's a host unreachable
>>       situation than the TCP stack would.  It may also take a router
>>       longer to detect the opposite.
> In my (naive?) understanding they not necessarily operate on a different
> timescale. For instance, it may take a router some time to execute an
> ARP request which may fail and then it would send a late ICMP (for the
> initial early segment, the later one got queued, then dropped). But if
> for whatever reason a port is disconnected (and by this a whole
> (sub-)net vanishes from the routing table) the router might be able to
> immediately (within an RTT) decide to send an ICMP. In either case the
> TCP source can decide about the timescale an arriving ICMP operates on
> (by looking at the sequence numbers therein). 

If the sequence numbers wrap, it can't tell much. Nothing guarantees
that ICMPs are generated before such wrap occurs - even assuming benign
behavior.

...
>> I don't think you gain very much, either.  If your application believes
>> that the connection has stuttered - a route flap or something - the
>> easiest way to fix it may be to reconnect.  I'll bet you do this a
>> couple times a day with your browser.  Hitting reload on a slow loading
>> page does exactly this.  Other applications may value continuity of
>> connection more.
> I exhibit exactly this behavior. And I don't like it. I'd like the
> network to solve these issues for me... :)

A "best effort" network doesn't provide that service. You may want a
circuit-oriented system.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

Re: [tcpm] Congestion control in face of ICMP unreachable messages

Attachment: signature.asc