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

Hi, Daniel, et al.,

Daniel Schaffrath wrote:
>> ...
>>>> 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.

Correct, but that's not relevant. Getting an ICMP message tells you a
single packet got to a certain point in the path; it doesn't say that
other packets didn't get dropped. It's not an indication of "no
congestion", as a result.

> Up to that node where the ICMP message is generated there as no
> congestion as the eliciting datagram was not dropped.

"No congestion" for that packet. Unless you get an ICMP for every packet
you sent, you can't assume that you have no congestion. However, since
routers are supposed to not send ICMPs that frequently (see RFC1812),
only a fraction of packets that arrive at a router would generate an
ICMP reply (even if all 'should').

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

Packets to the same destination from the same connection could go on a
different path and be delivered properly. The Internet makes no
guarantee that all packets travel the same path all the time, even
within a single flow.

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

An ICMP host/net unreachable doesn't indicate "no congestion", so
there's no reason to act differently when you get an individual such
message. If you get repeated such messages, the network is saying that
it can't find a way around a roadblock - presuming, however, that the
connection isn't making any progress. If it is, all you know is that
some of the multiple paths are broken. None of this has anything to do
with congstion, though.

> (As I feel we have agreed
> upon) RFCs say to back-off exponentially in that case.

For true congestion.

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

See above.

>> ...
>>> 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 doesn't say there's no congestion either. It doesn't need to say one
or the other!

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

That's violating other principles of TCP. Why is that justified because
of this?

> Really, you don't want waste of bandwidth, do you?

The Internet wastes bandwidth all the time. TCP probes waste bandwidth,
e.g. What we want to reduce is bandwidth that is wasted that could be
used for other connections - that's congestion. Sending packets when
there *might* be a roadblock (which is what a single ICMP host/net
unreachable means) isn't wasteful; it's needed for discovery of
alternate paths.

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