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

Acting in no official capacity, I say:

On Fri, Sep 07, 2007 at 12:13:51AM +0200, Daniel Schaffrath wrote:
> 
> On 2007/08/17  , at 18:25, Ted Faber wrote:
> 
> >On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote:
> >>Dear Community,
> >>
> >>I was wondering if there are any recommendations regarding congestion
> >>control in face of ICMP (host/network) unreachable messages. If I am
> >>not mistaken there is nothing in the various TCPM documents... nor in
> >>any RFC.
> >>
> >>Maybe you have any pointers?
> >
> >Sure.  If the code in the destination unreachable message is 2-4 abort
> >the connection.  Otherwise, don't.  RFC 1122.
> Ok... however, aborting a connection seems somewhat a bit too harsh  
> congestion control to me :)

Assuming you believe these are valid messages, those codes indicate that
the entity you want to talk to is not there or has gone away and isn't
coming back.  The sender is required to terminate the connection because
the network has told it that the receiver cannot be reached and that
further packets will not be delivered.  Sending any packets under those
conditions will just take up space until they're dropped.

> 
> >I wouldn't use ICMP reachability information in congestion control,
> >and I don't believe that any standard requires an implementer to do  
> >so.
> >If packets aren't being delivered, the sending endpoint(s) will slow
> >down pretty dramatically, pretty quickly without intervention.  A
> >retransmisson timeout puts the endpoint into slow start.
> Yes. And that exactly what I am after. Don't you think that this a  
> bit to conservative? Especially if you consider exponential back-off.  
> I mean, if TCP retransmits after RTO and gets no reply, this  
> indicates severe congestion and back-off is fine. But if it gets an  
> ICMP unreachable message again, this might allow a less conservative  
> behavior?

Huh?

If TCP has gotten to the point where a retransmission timer has gone off
not only has the transmission of the packet to be retransmitted failed,
but enough other packets have been lost that the fast retransmit
algorithm (3 dupacks) has also not happened (yes, the window needs to
have grown to 4...).  In short, there's something very wrong with the
communication between the endpoints, and drastic action is called for.
Specifically, the sender acts as though the connection is almost new -
window is as small as possible and the ssthresh is halved.

Your text above sounds like you're saying that if a sender has heard the
network say that there's a connectivity problem between the sender and
receiver (ICMP destination unreachable) the sender is entitled to react
less conservatively, even though all the evidence is that the link is
congested.

I don't understand that logic at all.  Even if you believe that the ICMP
messages indicate a transient condition and that the connection to the
receiver will eventually be restored, the sender's best information is
that something in the network is confused about how to the destination
(ICMP unreachable) and that the receiver is unable to communicate with
the sender (no ACKs for an RTO).  All evidence is that your packets are
doing no good and possible harm (congesting links over which they're
being wrongly routed).

Explain to me why ICMP messages indicating that your packets are not
being delivered indicate you should not slow down.

> 
> Another thing is that RTO needs to expire to reach slow-start  
> recovery. If my understanding of RFC 1122 is correct, it's still  
> standard compliant to continue sending after having received the  
> first appropriate ICMP message. Maybe that's a bit too aggressive (as  
> opposed to slow-start recovery after an "ICMP induced" RTO).

I believe your understanding of RFC 1122 is incorrect.  I don't believe
that receiving an ICMP message of any kind has any effect on the TCP
congestion control algorithms whatsoever (other than aborting the
connection in the case above).  ICMP messages are not part of a TCP
connection, and receiving one does not count as receiveing a TCP
packet, much less an ACK.  After all, an ICMP message may well be coming
from an intermediate gateway.

What text have I missed?

-- 
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