On Tue, Jan 21, 2014 at 9:40 PM, Ross Callon <rcallon(_at_)juniper(_dot_)net>
wrote:
If the upper layers (the thing that runs over the tunnel) involves
applications over TCP over IP, or if it is otherwise responding to congestion
in the same way that we expect anything running over IP to respond to
congestion, then we don't want the tunnel to also independently try to
respond to congestion (two independent cooks cooking the same meal does not
necessarily lead to success).
If the upper layer does not respond to congestion, then perhaps it shouldn't
be running over the open Internet (with or without a tunnel), unless the
*total* bandwidth that could be used is inherently quite low. On the other
hand, it might want to run within a data center or internally to a service
provider network with appropriate provisioning.
To paraphrase: if this problem exists in the new encapsulation, then
it exists already.
Lars is right, this does allow traffic that was formerly run over
provisioned paths in well-managed networks to possibly be part of
general Internet traffic. It would be good if there were a way to be
_sure_ there was e2e congestion control. But there is no signaling
between this low-layer UDP encapsulation and anything above it that
might already be reacting to congestion. There is no reasonably easy
way for it to know what it is carrying. Yes there is a way to do
congestion control at the bottom layer, but doing so could destroy
performance if one (or more) layer(s) is already doing it up above. We
have experience with that.
I can't remember who said it, but an applicability statement might
satisfy everyone, especially since it's been said (Curtis?) that this
just isn't going to be used in situations where congestion will be a
problem.
Alternatively, a paragraph laying out the problem and saying if this
is used in a way that could impact ordinary traffic, a mechanism must
be defined.
Scott