> From: "Eggert, Lars" <lars@xxxxxxxxxx>
> that danger is somewhat mitigated, because such traffic typically dies
> at the next NAT or firewall (unless that has been specifically
> provisioned, which is then also OK).
But such packets/protocols are usually not "provisioned" (i.e. specific
resources set aside to carry them). Generally, they are merely "allowed" - and
one then still has the potential of congestion at that device.
> Depends on the reach of that encapsulation. .. If it traversed such
> middleboxes by default, as UDP does, it has the same issues.
Exactly. The problem is not specific to UDP. So why is the discussion
(seemingly) trying to solve it in a UDP-specific way?
I repeat: even if people were _not_ using UDP encapsulations, the exact same
problem (of potential congestion caused by non-congestion-compliant
applications) would still exist. Switching to a different encapsulation method
is not going to get rid of _any_ potential congestion - not one packet's
worth.
So can we just drop all mention of UDP, since it's irrelevant to the _real_
problem?
>> But saying that _intermediate forwarding nodes_ have to detect
>> down-stream congestion, and respond, represents a fundamental change
>> to the Internet's architecture for congestion control.
> And here's the fallacy: UDP encapsulators are forwarding nodes *only*
> from the viewpoint of the final endpoints. From the viewpoint of the
> rest of the Internet, they are traffic *sources*, not *forwarders*.
I present two boxes. In one, a packet comes in, and after some manipulation of
headers, the packet goes out. In the other, a packet comes in, and after some
header changes, the packet goes out. You're trying to tell me that,
architecturally, one _is_ an intermediate forwarding node (which doesn't have
to detect downsteam congestion, and respond), and the other is not (and so
does have to)?
And I repeat: mandating that nodes which are forwarding nodes have to detect,
and respond to, downsteam congestion caused by non-congestion-compliant
traffic flowing _through_ them is a fundamental change to the Internet's
existing framework for congestion control.
Not that I'm opposed to such a change (it might make sense, I'd have to go
away and think about it), but if we're going to make such an architectural
change, i) we should do so explicitly, and ii) such a requirement should fall
on _all_ packet forwarding nodes - including regular routers, since they could
equally possibly be given non-congestion-compliant traffic to forward.
Noel