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

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

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

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

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.

...
> 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;
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. Getting the ICMP
effectively says you are NOT experiencing congestion.

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