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

On Thu, Sep 20, 2007 at 09:21:14PM +0200, Daniel Schaffrath wrote:
> 
> On 2007/09/14  , at 02:53, Ted Faber 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). Of course, provided all involved nodes being non-malicious.

Yeah, but that seems like a long run for a short slide to me, as a
private individual.  It might help in very simple cases, but there are a
couple "might"s in there and a TCP endpoint making a decision about an
ICMP packet based on matching sequence numbers.  Practically this seems
to be making TCP more brittle to deal with a pretty uncommon case.

> 
> >	* They're really easy to spoof.
> I got that in the meantime from Jon explanation. And how come, if  
> they are really that easy to spoof, that for ICMP port/proto/etc.  
> unreachable messages RFC 1122 asks to drop the connection? Isn't that  
> a very easy attack then. btw: I just noticed while browsing the Linux  
> source that Linux treats port/proto/net/host unreachable messages all  
> the same, i.e., flag an error on the socket and that's it.

Have you seen:

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tcpm-icmp-attacks-02.txt

Fernando and this group are looking at these issues.  Perhaps your ideas
can be combined with that document?

> 
> Anyways: if ICMP were used to skip doubling RTO an attacker cannot  
> make a TCP source to flood the network by this.

I don't think any of that is an obvious mechanism to cause a DoS attack.

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

I do it, too.  TCP serves a lot of applications that aren't people
browsing the web.

Why do you think TCP should handle this rather than Firefox (for
example)?

> 
> [...]
> 
> >>>Explain to me why ICMP messages indicating that your packets are not
> >>>being delivered indicate you should not slow down.
> >>
> >>I am not saying you shouldn't slow down. After RTO of course you
> >>should reset cwnd and halve ssthresh. I was just thinking of skipping
> >>(or delaying) doubling RTO if the retransmission after RTO does not
> >>simply vanish in the network but is  replied to with an ICMP (host/
> >>net) unreachable message. This seems reasonable to me if my above
> >>finding is true.
> >
> >I think its extra complexity for minimal gain.
> >But, I haven't done anything to validate that opinion.  Do you have  
> >some
> >evidence either way?
> 
> Complexity seems to be almost a dysphemism to me here.

Perhaps you think complexity is a dirtier word than I do.  It's hard
to understand how making TCP's retransmission depend partially on ICMP
isn't making TCP more complex.  I'm happy to use whatever term you
prefer.

>                                                        The gain is  
> obviously a much faster restarting connection. And it's  
> extraordinary... given an adequate scenario which is of course not  
> the usual dial-up leafnode to the wired Internet but for instance a  
> node which is part of a subnet managed by olsrd (causing route  
> interruptions and the like).

It seems like the case you're considering - a TCP connection that has a
conncectivity breach that's noticed by ICMP and restored within a few
RTTs - is pretty uncommon.  Many application protocols (HTTP,FTP) are
already prepared to deal with these kind of interruptions.  Again, I
don't see a compelling case for the benefits.  Just speaking for myself.

> 
> The question is if there is some rationale for this behavior.  
> Actually, I was thinking there was (ICMP reply for single slow-start  
> recovery retransmit indicating no congestion for the first few hops  
> at least). But in the meantime I found that for zero window probing  
> (which is comparable to "roadblock" probing) RFC 1122 in 4.2.2.17  
> recommends  exponentiell back-off as well. Whereas I understand  that  
> exponentiell back-off is necessary for the _network_ to recover from  
> severe congestion, I don't understand why exponentiell back-off is  
> recommended for recovering from zero windows (which is more or less  
> _application_ congestion). Of course, for zero window probes which  
> are not ACKed back-off is essentiel. There is a DISCUSSION paragraph  
> in 4.2.2.17 which is unfortunately not clear to me. It might be  
> understood as if exponentiell back-off allows fast recovery from a  
> zero window condition, although (from my understanding) it does  
> exactly the opposite. Of course, it may all boil down to defining  
> words, i.e., exponentiell back-off being fast by definition as  
> complexity theory knows off much worse growth. But "traditionally"  
> exponentiell is not fast.

4.2.2.17 is dealing with the case that one end of the connection is
advertising a 0 size window.  In this case the other end knows that the
connection still exists, but it isn't accepting data.  That whole
probing operation is to elicit a window update if one has been lost.

In general, TCP is conservative with sending probes of any kind.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG