<div><div dir="auto">Thanks for the insights.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun 23 Jun 2019 at 00:25, David P. Reed <<a href="mailto:dpreed@deepplum.com">dpreed@deepplum.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="arial" size="3"><p style="margin:0;padding:0;font-family:arial;font-size:12pt">Given the complexity of my broader comments, let me be clear that I have no problem with the broad concept of diffserv being compatible with the end-to-end arguments. I was trying to lay out what I think is a useful way to think about these kinds of issues within the Internet context.</p>
<p style="margin:0;padding:0;font-family:arial;font-size:12pt"> </p>
<p style="margin:0;padding:0;font-family:arial;font-size:12pt">Similarly, per-flow scheduling as an end-to-end concept (different flows defined by address pairs being jointly managed as entities) makes great sense, but it's really important to be clear that queue prioritization within a single queue at entry to a bottleneck link is a special case mechanism, and not a general end-to-end concept at the IP datagram level, given the generality of IP as a network packet transport protocol. It's really tied closely to routing, which isn't specified in any way by IP, other than "best efforts", a term that has become much more well defined over the years (including the notions of dropping rather than storing packets, the idea that successive IP datagrams should traverse roughly the same path in order to have stable congestion detection, ...).</p>
<p style="margin:0;padding:0;font-family:arial;font-size:12pt"> </p>
<p style="margin:0;padding:0;font-family:arial;font-size:12pt">Per-flow scheduling seems to work quite well in the cases where it applies, transparently below the IP datagram layer (that is, underneath the hourglass neck). IP effectively defines "flows", and it is reasonable to me that "best efforts" as a concept could include some notion of network-wide fairness among flows. Link-level "fairness" isn't a necessary precondition to network level fairness.</p></font><font face="arial" size="3">
<p style="margin:0;padding:0;font-family:arial;font-size:12pt"> </p>
<p style="margin:0;padding:0;font-family:arial;font-size:12pt">On Saturday, June 22, 2019 5:10pm, "Brian E Carpenter" <<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>> said:<br><br></p>
<div id="m_-3088807467043093840SafeStyles1561241483">
<p style="margin:0;padding:0;font-family:arial;font-size:12pt">> Just three or four small comments:<br>> <br>> On 23-Jun-19 07:50, David P. Reed wrote:<br>> > Two points:<br>> ><br>> >  <br>> ><br>> > - Jerry Saltzer and I were the primary authors of the End-to-end argument<br>> paper, and the motivation was based *my* work on the original TCP and IP<br>> protocols. Dave Clark got involved significantly later than all those decisions,<br>> which were basically complete when he got involved. (Jerry was my thesis<br>> supervisor, I was his student, and I operated largely independently, taking input<br>> from various others at MIT). I mention this because Dave understands the<br>> end-to-end arguments, but he understands (as we all did) that it was a design<br>> *principle* and not a perfectly strict rule. That said, it's a rule that has a<br>> strong foundational argument from modularity and evolvability in a context where<br>> the system has to work on a wide range of infrastructures (not all knowable in<br>> advance) and support a wide range of usage/application-areas (not all knowable in<br>> advance). Treating the paper as if it were "DDC" declaring a law is just wrong. He<br>> wasn't Moses and it is not written on tablets. Dave<br>> > did have some "power" in his role of trying to achieve interoperability<br>> across diverse implementations. But his focus was primarily on interoperability,<br>> not other things. So ideas in the IP protocol like "TOS" which were largely<br>> placeholders for not-completely-worked-out concepts deferred to the future were<br>> left till later.<br>> <br>> Yes, well understood, but he was in fact the link between the e2e paper and the<br>> differentiated services work. Although not a nominal author of the "two-bit" RFC,<br>> he was heavily involved in it, which is why I mentioned him. And he was very<br>> active in the IETF diffserv WG.<br>> > - It is clear (at least to me) that from the point of view of the source of<br>> an IP datagram, the "handling" of that datagram within the network of networks can<br>> vary, and so that is why there is a TOS field - to specify an interoperable,<br>> meaningfully described per-packet indicator of differential handling. In regards<br>> to the end-to-end argument, that handling choice is a network function, *to the<br>> extent that it can completely be implemented in the network itself*.<br>> ><br>> > Congestion management, however, is not achievable entirely and only within<br>> the network. That's completely obvious: congestion happens when the<br>> source-destination flows exceed the capacity of the network of networks to satisfy<br>> all demands.<br>> ><br>> > The network can only implement *certain* general kinds of mechanisms that may<br>> be used by the endpoints to resolve congestion:<br>> ><br>> > 1) admission controls. These are implemented at the interface between the<br>> source entity and the network of networks. They tend to be impractical in the<br>> Internet context, because there is, by a fundamental and irreversible design<br>> choice made by Cerf and Kahn (and the rest of us), no central controller of the<br>> entire network of networks. This is to make evolvability and scalability work. 5G<br>> (not an Internet system) implies a central controller, as does SNA, LTE, and many<br>> other networks. The Internet is an overlay on top of such networks.<br>> ><br>> > 2) signalling congestion to the endpoints, which will respond by slowing<br>> their transmission rate (or explicitly re-routing transmission, or compressing<br>> their content) through the network to match capacity. This response is done<br>> *above* the IP layer, and has proven very practical. The function in the network<br>> is reduced to "congestion signalling", in a universally understandable meaningful<br>> mechanism: packet drops, ECN, packet-pair separation in arrival time, ... <br>> This limited function is essential within the network, because it is the state of<br>> the path(s) that is needed to implement the full function at the end points. So<br>> congestion signalling, like ECN, is implemented according to the end-to-end<br>> argument by carefully defining the network function to be the minimum necessary<br>> mechanism so that endpoints can control their rates.<br>> ><br>> > 3) automatic selection of routes for flows. It's perfectly fine to select<br>> different routes based on information in the IP header (the part that is intended<br>> to be read and understood by the network of networks). Now this is currently<br>> *rarely* done, due to the complexity of tracking more detailed routing information<br>> at the router level. But we had expected that eventually the Internet would be so<br>> well connected that there would be diverse routes with diverse capabilities. For<br>> example, the "Interplanetary Internet" works with datagrams, that can be<br>> implemented with IP, but not using TCP, which requires very low end-to-end<br>> latency. Thus, one would expect that TCP would not want any packets transferred<br>> over a path via Mars, or for that matter a geosynchronous satellite, even if the<br>> throughput would be higher.<br>> ><br>> > So one can imagine that eventually a "TOS" might say - send this packet<br>> preferably along a path that has at most 200 ms. RTT, *even if that leads to<br>> congestion signalling*, while another TOS might say "send this path over the most<br>> "capacious" set of paths, ignoring RTT entirely. (these are just for illustration,<br>> but obviously something like this woujld work).<br>> ><br>> > Note that TOS is really aimed at *route selection* preferences, and not<br>> queueing management of individual routers.<br>> <br>> That may well have been the original intention, but it was hardly mentioned at all<br>> in the diffserv WG (which I co-chaired), and "QOS-based routing" was in very bad<br>> odour at that time.<br>>  <br>> ><br>> > Queueing management to share a single queue on a path for multiple priorities<br>> of traffic is not very compatible with "end-to-end arguments". There are any<br>> number of reasons why this doesn't work well. I can go into them. Mainly these<br>> reasons are why "diffserv" has never been adopted -<br>> <br>> Oh, but it has, in lots of local deployments of voice over IP for example. It's<br>> what I've taken to calling a limited domain protocol. What has not happened is<br>> Internet-wide deployment, because...<br>> <br>> > it's NOT interoperable because the diversity of traffic between endpoints is<br>> hard to specify in a way that translates into the network mechanisms. Of course<br>> any queue can be managed in some algorithmic way with parameters, but the<br>> endpoints that want to specify an end-to-end goal don't have a way to understand<br>> the impact of those parameters on a specific queue that is currently congested.<br>> <br>> Yes. And thanks for your insights.<br>> <br>> Brian<br>> <br>> ><br>> >  <br>> ><br>> > Instead, the history of the Internet (and for that matter *all* networks,<br>> even Bell's voice systems) has focused on minimizing queueing delay to near zero<br>> throughout the network by whatever means it has at the endpoints or in the design.<br>> This is why we have AIMD's MD as a response to detection of congestion.<br>> ><br>> >  <br>> ><br>> > Pragmatic networks (those that operate in the real world) do not choose to<br>> operate with shared links in a saturated state. That's known in the phone business<br>> as the Mother's Day problem. You want to have enough capacity for the rare<br>> near-overload to never result in congestion.  Which means that the normal<br>> state of the network is very lightly loaded indeed, in order to minimize RTT.<br>> Consequently, focusing on somehow trying to optimize the utilization of the<br>> network to 100% is just a purely academic exercise. Since "priority" at the packet<br>> level within a queue only improves that case, it's just a focus of (bad) Ph.D.<br>> theses. (Good Ph.D. theses focus on actual real problems like getting the queues<br>> down to 1 packet or less by signalling the endpoints with information that allows<br>> them to do their job).<br>> ><br>> >  <br>> ><br>> > So, in considering what goes in the IP layer, both its header and the<br>> mechanics of the network of networks, it is those things that actually have<br>> implementable meaning in the network of networks when processing the IP datagram.<br>> The rest is "content" because the network of networks doesn't need to see it.<br>> ><br>> >  <br>> ><br>> > Thus, don't put anything in the IP header that belongs in the "content" part,<br>> just being a signal between end points. Some information used in the network of<br>> networks is also logically carried between endpoints.<br>> ><br>> >  <br>> ><br>> >  <br>> ><br>> > On Friday, June 21, 2019 4:37pm, "Brian E Carpenter"<br>> <<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>> said:<br>> ><br>> >> Below...<br>> >> On 21-Jun-19 21:33, Luca Muscariello wrote:<br>> >> > + David Reed, as I'm not sure he's on the ecn-sane list.<br>> >> ><br>> >> > To me, it seems like a very religious position against per-flow<br>> >> queueing. <br>> >> > BTW, I fail to see how this would violate (in a "profound" way ) the<br>> e2e<br>> >> principle.<br>> >> ><br>> >> > When I read it (the e2e principle)<br>> >> ><br>> >> > Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End<br>> Arguments in<br>> >> System Design". <br>> >> > In: Proceedings of the Second International Conference on<br>> Distributed<br>> >> Computing Systems. Paris, France. <br>> >> > April 8–10, 1981. IEEE Computer Society, pp. 509-512.<br>> >> > (available on line for free).<br>> >> ><br>> >> > It seems very much like the application of the Occam's razor to<br>> function<br>> >> placement in communication networks back in the 80s.<br>> >> > I see no conflict between what is written in that paper and per-flow<br>> queueing<br>> >> today, even after almost 40 years.<br>> >> ><br>> >> > If that was the case, then all service differentiation techniques<br>> would<br>> >> violate the e2e principle in a "profound" way too,<br>> >> > and dualQ too. A policer? A shaper? A priority queue?<br>> >> ><br>> >> > Luca<br>> >><br>> >> Quoting RFC2638 (the "two-bit" RFC):<br>> >><br>> >> >>> Both these<br>> >> >>> proposals seek to define a single common mechanism that is<br>> used<br>> >> by<br>> >> >>> interior network routers, pushing most of the complexity and<br>> state<br>> >> of<br>> >> >>> differentiated services to the network edges.<br>> >><br>> >> I can't help thinking that if DDC had felt this was against the E2E<br>> principle,<br>> >> he would have kicked up a fuss when it was written.<br>> >><br>> >> Bob's right, however, that there might be a tussle here. If end-points<br>> are<br>> >> attempting to pace their packets to suit their own needs, and the network<br>> is<br>> >> policing packets to support both service differentiation and fairness,<br>> >> these may well be competing rather than collaborating behaviours. And<br>> there<br>> >> probably isn't anything we can do about it by twiddling with algorithms.<br>> >><br>> >> Brian<br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >> ><br>> >> ><br>> >> ><br>> >> ><br>> >> ><br>> >> ><br>> >> >  <br>> >> ><br>> >> > On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller<br>> <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a><br>> >> <mailto:<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>>> wrote:<br>> >> ><br>> >> ><br>> >> ><br>> >> > > On Jun 19, 2019, at 16:12, Bob Briscoe <<a href="mailto:ietf@bobbriscoe.net" target="_blank">ietf@bobbriscoe.net</a><br>> >> <mailto:<a href="mailto:ietf@bobbriscoe.net" target="_blank">ietf@bobbriscoe.net</a>>> wrote:<br>> >> > ><br>> >> > > Jake, all,<br>> >> > ><br>> >> > > You may not be aware of my long history of concern about how<br>> >> per-flow scheduling within endpoints and networks will limit the Internet<br>> in<br>> >> future. I find per-flow scheduling a violation of the e2e principle in<br>> such a<br>> >> profound way - the dynamic choice of the spacing between packets - that<br>> most<br>> >> people don't even associate it with the e2e principle.<br>> >> ><br>> >> > Maybe because it is not a violation of the e2e principle at all? My<br>> point<br>> >> is that with shared resources between the endpoints, the endpoints simply<br>> should<br>> >> have no expectancy that their choice of spacing between packets will be<br>> conserved.<br>> >> For the simple reason that it seems generally impossible to guarantee<br>> that<br>> >> inter-packet spacing is conserved (think "cross-traffic" at the<br>> bottleneck hop<br>> >> along the path and general bunching up of packets in the queue of a fast<br>> to slow<br>> >> transition*). I also would claim that the way L4S works (if it works) is<br>> to<br>> >> synchronize all active flows at the bottleneck which in tirn means each<br>> sender has<br>> >> only a very small timewindow in which to transmit a packet for it to hits<br>> its<br>> >> "slot" in the bottleneck L4S scheduler, otherwise, L4S's low queueing<br>> delay<br>> >> guarantees will not work. In other words the senders have basically no<br>> say in the<br>> >> "spacing between packets", I fail to see how L4S improves upon FQ in that<br>> regard.<br>> >> ><br>> >> ><br>> >> >  IMHO having per-flow fairness as the defaults seems quite<br>> >> reasonable, endpoints can still throttle flows to their liking. Now<br>> per-flow<br>> >> fairness still can be "abused", so by itself it might not be sufficient,<br>> but<br>> >> neither is L4S as it has at best stochastic guarantees, as a single queue<br>> AQM<br>> >> (let's ignore the RFC3168 part of the AQM) there is the probability to<br>> send a<br>> >> throtteling signal to a low bandwidth flow (fair enough, it is only a<br>> mild<br>> >> throtteling signal, but still).<br>> >> > But enough about my opinion, what is the ideal fairness measure in<br>> your<br>> >> mind, and what is realistically achievable over the internet?<br>> >> ><br>> >> ><br>> >> > Best Regards<br>> >> >         Sebastian<br>> >> ><br>> >> ><br>> >> ><br>> >> ><br>> >> > ><br>> >> > > I detected that you were talking about FQ in a way that might<br>> have<br>> >> assumed my concern with it was just about implementation complexity. If<br>> you (or<br>> >> anyone watching) is not aware of the architectural concerns with<br>> per-flow<br>> >> scheduling, I can enumerate them.<br>> >> > ><br>> >> > > I originally started working on what became L4S to prove that<br>> it was<br>> >> possible to separate out reducing queuing delay from throughput<br>> scheduling. When<br>> >> Koen and I started working together on this, we discovered we had<br>> identical<br>> >> concerns on this.<br>> >> > ><br>> >> > ><br>> >> > ><br>> >> > > Bob<br>> >> > ><br>> >> > ><br>> >> > > --<br>> >> > ><br>> ________________________________________________________________<br>> >> > > Bob Briscoe             <br>>  <br>> >>              <br>>  <a href="http://bobbriscoe.net/" target="_blank">http://bobbriscoe.net/</a><br>> >> > ><br>> >> > > _______________________________________________<br>> >> > > Ecn-sane mailing list<br>> >> > > <a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>> >> <mailto:<a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a>><br>> >> > > <a href="https://lists.bufferbloat.net/listinfo/ecn-sane" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>> >> ><br>> >> > _______________________________________________<br>> >> > Ecn-sane mailing list<br>> >> > <a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>> >> <mailto:<a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a>><br>> >> > <a href="https://lists.bufferbloat.net/listinfo/ecn-sane" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>> >> ><br>> >><br>> >><br>> ><br>> <br>> </p>
</div></font></blockquote></div></div>