+1 Alia - Nice concise summary. Thanks. Curtis In message <CAG4d1rf+wAJuD2GvYfm14bOoEvbhqq0azN5fOq35aPJDUvg=gw@xxxxxxxxxxxxxx> Alia Atlas writes: > > I don't want to get in the way of vehement discussion, but I thought > we were on the verge of finding an actual solution... > > IMHO, that was a combination of an applicability statement, using > SHOULD for congestion control and checksum, and defining a longer-term > OAM-based approach (as Stewart Bryant suggested) to be able to verify > that packet corruption or excessive drops aren't happening. > > Does that sound like an acceptable set? > > Alia > > > On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch <touch@xxxxxxx> wrote: > > > > > > > On 1/23/2014 3:32 PM, Edward Crabbe wrote: > > > >> Joe, thanks for your response. Comments inline: > >> > >> > >> On 1/23/2014 1:27 PM, Edward Crabbe wrote: > >> > >> Part of the point of using UDP is to make use of lowest common > >> denominator forwarding hardware in introducing entropy to > >> protocols that > >> lack it ( this is particularly true of the GRE in UDP use case > >> also > >> under discussion elsewhere). > >> > >> The tunnel is not the source of the traffic. The _source of the > >> traffic_ is the source of the traffic. > >> > >> > >> To the Internet, the tunnel encapusulator is the source of traffic. > >> Tracing the data back further than that is a mirage at best - and > >> irrelevant. > >> > >> > >> The 'internet' cares about characteristics of reactivity to congestion. > >> This is guaranteed by the /source of the traffic/ independent of any > >> intermediate node. > >> > > > > Are you prepared to make that a requirement of this document, i.e., that > > the only MPLS traffic that can be UDP encapsulated is known to react to > > congestion? > > > > How exactly can you know that? > > > > > > The tunnel head-end is responsible for the tunnel walking, talking, > >> and quaking like a duck (host). When the tunnel head-end knows > >> something about the ultimate origin of the traffic - whether real, > >> imagined, or from Asgard - then it has done it's duty (e.g., that > >> it's already congestion controlled). > >> > >> But that head end is responsible, regardless of what it knows or > >> doesn't. And when it doesn't know, the only way to be responsible is > >> to put in its own reactivity. > >> > >> This is not fact; it's actually precisely the principle we're currently > >> arguing about. ;) > >> > > > > Actually, it's a paraphrasing of Section 3.1.3 of RFC5405. > > > > We can continue to debate it, but until it's been *changed* by a revision, > > it remains BCP. > > > > > > I would posit: > >> > >> The tunnel doesn't have to know anything about congestion or performance > >> characteristics because the originating application must. > >> > > > > That works only if you know that fact about the originating application. > > However, there are plenty of applications whose traffic goes over MPLS that > > isn't congestion reactive or bandwidth-limited. > > > > > > > See GRE, > > > >> MPLS, many other tunnel types, > >> > > > > This isn't an issue for all tunnels until they enter the Internet... > > > > > > including several existing within the > >> IETF that make use of an outer UDP header. > >> > > > > Which are all already supposed to follow the recommendations of RFC5405. > > To the extent that they don't, they don't agree with that BCP. > > > > I'm not saying such things never can or will exist, but I don't think the > > IETF should be self-contradictory. We already agreed as a group on such > > BCPs and other standards, and new standards-track docs need to follow them. > > > > > > The originating application > >> who's traffic is being tunneled should be responsible for > >> congestion > >> control, or lack there of. > >> > >> Perhaps it should be, but that's an agreement between whomever > >> implements/deploys the tunnel headend and whomever provides the > >> originating traffic to them. The problem is that this isn't true for > >> the typical use case for this kind of encapsulation. > >> > >> How so? As mentioned before, this is the same case as standard GRE/MPLS > >> etc. > >> > > > > It's putting MPLS inside UDP. That's a different case, and the reason > > RFC5405 applies. > > > > > > I.e., if we were talking about MPLS traffic that already was > >> reactive, we wouldn't be claiming the need for additional > >> encapsulator mechanism. It's precisely because nothing is known > >> about the MPLS traffic that the encapsulator needs to act. > >> > >> The MPLS traffic doesn't have to be reactive, it's the applications > >> being encapsulated / traversing a particular tunnel that are responsible > >> for and aware of path and congestion charateristics. Because the MPLS > >> head end knows nothing about the /end to end application 'session'/ > >> characteristics it /shouldn't/ have anything to do with congestion > >> management. > >> > > > > OK, so what you're saying is that "traffic using this encapsulation MUST > > be known to be congestion reactive". Put that in the doc and we'll debate > > whether we believe it. > > > > But right now you're basically saying that because you think it's someone > > else's problem (the originating application), it isn't yours. The > > difficulty with that logic is that you (the tunnel headend) is responsible > > to ensure that this is true - either by *knowing* that the originating > > traffic is congestion reactive, or by putting in its own mechanism to > > ensure that this happens if the originating application isn't. > > > > > > > Are we advocating a return to intermediate > >> > >> congestion control (I like X.25 as much as the next guy, > >> but...). This > >> is a very stark change of direction. > >> > >> I think mandating congestion control is not technically sound > >> from > >> either a theoretical (violation of end to end principle, stacking > >> of > >> congestion control algorithms leading to complex and potentially > >> suboptimal results) or economic perspective (as a very large > >> backbone, > >> we've been doing just fine without intermediate congestion > >> management > >> thank you very much, and I have 0 desire to pay for a cost > >> prohibitive, > >> unnecessary feature in silicon.) > >> > >> Write that up, and we'll see how it turns out in the IETF. However, > >> right now, the IETF BCPs do require reactive congestion management > >> of transport streams. > >> > >> Which part? The end-to-end principle, or the aversion to congestion > >> control stacking? These have been implicit in all tunneling protocols > >> produced by the IETF for the modern internet. > >> > > > > Sure, and that's reflected in RFC5405 already. However, please, PLEASE > > appreciate that NOBODY here is asking you to put in "congestion control > > stacking"; that happens when you run two dynamic, reactive control > > algorithms using the same timescale on top of each other. > > > > Equally well-known in CC circles is that you CAN - and often *should* - > > stack different kinds of mechanisms at different layers with different > > timescales. E.g., that's why we have an AQM WG - because even when all the > > traffic is TCP, that's not quite enough inside the network. That's also why > > Lars was suggesting something coarse on a longer timescale - a circuit > > breaker - rather than AIMD on a RTT basis. > > > > Keep in mind as well that the E2E argument says that you can't get an E2E > > service by composing the equivalent HBH one; it also says that HBH > > mechanisms can be required for efficiency. That's what we're talking about > > here - the efficiency impact of congestion, not the overall correctness of > > E2E control. > > > > > > If you don't want/like that, then either don't use transport > >> encapsulation, or change the BCPs. > >> > >> These BCPs are defined for an originating /application/. > >> > > > > Yes, and I don't understand why you (and others) keep thinking it matters > > that there are layers of things behind the tunnel head end. It doesn't - > > unless you KNOW what those layers are, and can ensure that they behave as > > you expect. > > > > > > In this case > >> the UDP header is simply a shim header applied to existing application > >> traffic. > >> > > > > It's not "simply a shim" - if that's the case, use IP and we're done. No > > need for congestion control. > > > > The reason congestion issues arise is because you're inserting a header > > ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****. > > > > If you put in a UDP-like header that nobody in the Internet would > > interpret, this wouldn't be an issue. > > > > But you simply cannot expect the Internet to treat you like "application" > > traffic if you won't enforce acting like that traffic too. > > > > > > The tunnel head does not introduce traffic independent of the > >> originating application. > >> > > > > The Internet ****neither knows nor cares****. > > > > To the Internet, the head-end is the source. Whatever data the head end > > puts inside the UDP packets *is application data* to the rest of the > > Internet. > > > > Again, if you are saying that you know so much about the originating > > source that you know you don't need additional mechanism at the headend, > > say so - but then live by that requirement. > > > > If *any* MPLS traffic could show up at the headend, then it becomes the > > headend's responsibility to do something. > > > > --- > > > > Consider the following case: > > > > - video shows up inside the OS, destined for the network > > > > - software X bundles that video and sends it to go out > > > > - software Y puts that data into UDP packets to go > > to the Internet > > > > So what's the "application" here? To the Internet, it's software Y -- the > > thing that puts the 'application' data into UDP packets. The previous steps > > are irrelevant - just as irrelevant as the singer your video camera is > > filming, as irrelevant as the sun that created the light that is reflected > > off the singer to your camera. > > > > If software Y knows so much about the steps that lead to its input data > > that it knows it's congestion reactive, nothing more need be done. > > > > If NOT (and that's the relevant corollary here), then it becomes software > > Y's responsibility to put in some reactivity. > > > > Joe