On Fri, Aug 9, 2019 at 6:42 PM Geoff Huston <[email protected]> wrote: > > > > > Geoff, > > > > The broad measurements are almost always a limited viewpoint taken at point > > in time. > > I was referring to Internet measurements using the Internet. The conversation > was (I thought) about the prospects for ever cleaning up Internet middleware > on the Internet. The context of the conversation was the context of applic > ations behaviour __on the Internet__. > Geoff,
I don't see that distinction being made in the draft. Consider the examples in section 5.3 examples of protocols that rely on fragmentation. These include OSPF, Packet-in-Packet encapsulation (e.g. GRE), and UDP enhancing performance protocols like Licklider Transmission Protocol. AFAIK, these protocols are either primarily or always used in a controlled environment (the only example in section 5.3 of a protocol commonly used on the Internet is DNS.). Furthermore, if they rely on fragmentation then they have been for many years and it has long been deployed. Maybe I missed it, but I don't believe we've been getting widespread reports of outages caused by fragmentation, nor do we have users clamoring for change. I don't see how these protocols are broken, nor the argument that after all these years we've been doing something wrong or violating the standard. But the next section states: "Legacy protocols that depend upon IP fragmentation SHOULD be updated to break that dependency." Presumably, this advice applies to the protocols discussed in section 5.3 which again doesn't differentiate protocols on the Internet versus those used in controlled networks. So this advice begs the question: is the draft suggesting to fix things that aren't actually broken? Conversely, one could also ask: is the draft doing enough to encourage fixing things that are actually broken (namely nonconformant implementations)? Tom > Of course there are many other contexts. Decnet Phase III may be doing just > fine in some of them and I’m sure there are many protocols and many variants > are being used in many contexts. If we were ever to attempt to interpret RFCs > as containing some eternal and universally applicable truth about IP as used > in every possible context in every possible way then I for one am cheerfully > prepared to give up at once, as I believe that this is a Sysyphalian task. > > > As discussed several times in regards to fragmentation, it's not broken for > > everyone all the time. It is being used productively in some contexts. > > > Of course - but the advice is not about what may work on Thursdays on a sunny > day on a downhill slope. Its more about lowest common denominator set of > pragmatic considerations that start with the premise that if you have no idea > where or why your application may be used, then what would be a sensible set > of design choices that would maximise its applicability and robustness, > irrespective of the day of the week, the inclination of the bits and the > outside temperature. > > Like I said its about interpretation of these IETF documents. If you believe > that RFCs are like some Networking Canon of immutable laws of moving bits > then yes, many things work in many situations and its just not possible to > say outright “this will not work in every case!” about almost everything. But > in my mind this document is not striving for any such lofty goal. It’s > pointing out that IP fragmentation is extremely fragile, and in IPv6 more so. > As an app designer and if you are desirous of maximising robustness and > applicability for you application then you should steer clear of > fragmentation, if you can. > > regards, > > Geoff > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
