On 1/21/2014 8:03 PM, Scott Brim wrote:
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.
Lars isn't suggesting congestion control on the same timescale as TCP, which is where the problem would be.
Long-timescale control OR something as simple as a throttle-cap would be sufficient.
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.
If we accepted that premise, we wouldn't need any congestion control. Nobody openly claims to want to generate congestion.
Congestion control is required to protect the rest of us from cases where that claim turns out to be false (typically because the protocol designers/use case authors turned out to be wrong).
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.
The problem is very clearly already stated in RFC5405. I can't see how this mechanism would ever be used if not for ordinary traffic.
So yes, a mechanism must be defined IMO too. Joe