On Tue, Jan 21, 2014 at 9:40 PM, Ross Callon <rcallon@xxxxxxxxxxx> 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