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

On 2007/09/13  , at 05:15, Joe Touch wrote:
> Daniel Schaffrath wrote:
>> On 2007/09/07  , at 02:43, Ted Faber wrote:
>>> Acting in no official capacity, I say:
>> Sorry, I don't get this.
>
> Ted is chair of the working group; he's taking that hat off in this
> reply ;-)
I see. I still don't get why he feels there is some need to reply  
"unofficially". Because of "Huh?"..?

> ...
>>> 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 :)
>
> Congestion is "packets that slows down or drops other packets".
>
> Packets sent to unavailable ports may have nothing to do with  
> congestion
> - they don't have to compete for resources. It's not about  
> relieving the
> network from congestion - congestion control handles that.
>
> A good example: UDP has no congestion control, but can generate ICMP
> responses.
>
> ...
>>> 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.
>
> The ICMP travels on the reverse path; there could be congestion in the
> forward path.
There could be congestion only in that part of the path which the  
datagram eliciting the ICMP message has not yet travelled through,  
though. Up to that node where the ICMP message is generated there as  
no congestion as the eliciting datagram was not dropped.

> ...
>>> 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.
>
> Host/net unreachable means that you sent some packets along a path  
> that
> couldn't reach that host/net. That's not to say that other packets
> wouldn't be delivered properly.
You mean other packet to be packets to another destination? Not other  
packet to the same destination (but from a different connection)?

> It's like hitting a roadblock on the way across town. It doesn't  
> say the
> endpoint is dead; that's why you don't give up, and also why you need
> not change your congestion parameters. Finding a bad path could happen
> by a routing transient - if you get these replies over a RTT, then  
> maybe
> you give up. Or two RTTs. That's why 1122 doesn't say to ignore  
> these -
> it says to use them as a hint. They're a hint that something can't be
> reached - not that there's congestion.
Yes. That is exactly my understanding. But as you (kindly) explain to  
me exactly my understanding I am really desperate what from my above  
writing could make you think that I have a different understanding. I  
am just talking about what to do if after a RTO exceeded the  
retransmission is replied to with an ICMP (host/net) unreachable  
message instead of no reply at all (indicating true congestion). (As  
I feel we have agreed upon) RFCs say to back-off exponentially in  
that case. Whereas I feel skipping further back-off might be non- 
contraproductive  (BUT performance enhancing as it allow faster  
recovery!) as there is no evidence of congestion in the network (at  
least not for the very part of the path which is involved of the  
delivery of the ICMP unreachable message... if there is congestion in  
the rest of the path, it would be immediately discovered after the  
faster recovery).

> ...
>> 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.
>
> Correct.
>
>> 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.
>
> It's consistent within 1122. The message doesn't say there's  
> congestion;
Yes!

> it says routing doesn't work for the packet you sent. It may be a  
> waste
> of bandwidth, but that's not the same as congestion - if you're  
> actually
> competing for resources others need, your data packet would have been
> dropped and you wouldn't get an ICMP at all.
I really don't get this. With the same argument I could justify that  
a hacked/modified TCP (which for instance increases cwnd by two  
(instead of one) MSS for each ACK in slow-start) is just fine...

Really, you don't want waste of bandwidth, do you? Of course,  
considering the hint you gave in the other email about late ICMP,  
it's no necessarily a waste, as in case of late ICMPs the issue might  
already have been resolved in the meantime.

> Getting the ICMP
> effectively says you are NOT experiencing congestion.
>
> Joe

Thank you once again,
Daniel

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