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

On 2007/09/07  , at 02:43, Ted Faber wrote:

> Acting in no official capacity, I say:
Sorry, I don't get this.

> 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 was actually joking about the term "congestion control". To me  
_congestion_ control is about how much to send and not whether to  
send at all. Of course, I understand that the latter is included in  
the former... in some way :)

>>> 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.
 From my understanding the evidence is that just some link is (was)  
not working and that is not the same as a link is congested. Even,  
there is some slight indication that there is no congestion in the  
network (or at least the very part of it) as the ICMP message (as  
well as the segment eliciting the ICMP message) was not dropped and  
got to the TCP source.

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

>> 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.
Maybe my paragraph above was not clear. I am not saying that RFC 1122  
suggests ICMP messages to have effect on cwnd. I am saying that from  
my understanding RFC 1122 allows  a TCP to continue sending segments  
after having received an ICMP host/net unreachable message. This  
seems to me as a waste of bandwidth as the arrival of the ICMP  
message just indicated that right now there is no route to the  
destination. Doesn't that sound reasonable? But maybe continuing  
sending makes sense together with some other RFC I am not aware of  
but someone else on the list.

> What text have I missed?

I don't know. How come you feel you missed some text??

Thanks again!
Daniel Schaffrath

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm