On Fri, Nov 30, 2018 at 12:39 PM Fred Baker <fredbaker.i...@gmail.com> wrote: > > > > On Nov 30, 2018, at 11:12 AM, Tom Herbert <t...@herbertland.com> wrote: > > It's pretty obvious that fragmentation isn't currently feasible on the > > open Internet, but for other environments, like the datacenter, it may > > not only be relevant but desirable compared to other solutions. > > > > While the draft doesn't deprecate IP fragmentation, it does say > > "Protocol developers SHOULD NOT develop new protocols that rely on IP > > fragmentation.". That's a pretty negative and general statement > > against fragmentation. Without more qualification, I'm not sure > > getting consensus on this recommendation will be easy. > > Thank you for your constructive comment. It at least gives us a direction to > try to improve the draft in. > > Two thoughts: > > "SHOULD" means, per RFC 2119, that it is a case in which the author would > like to make a blanket statement but recognizes that there may be exceptions > that s/he has not considered, and requires an implementor that doesn't follow > the mandate to state the exception. In this case, a new protocol that uses IP > fragmentation rather than using some higher layer would be expected to say > why - the default interpretation being that s/he was lazy or ignorant and > couldn't be bothered. In the event that a new protocol is developed that > depends on IP fragmentation, would you argue that the developer should not be > asked to think about and respond to the question "why"? > Bear in mind that "application developers" is a very broad category of people that include commercial developers, students, amateurs, etc. Right now, it's pretty easy to write a meaningful UDP application in just a couple of hours. I'm not sure it's reasonable for the college student writing a quick UDP app in their dorm room to have to consider all the pitfalls of fragmentation and whether they need to increase their complexity by an order of magnitude to implement fragmentation in their application. The promise of doing IP fragmentation at the network layer is that the application developer doesn't need to be concerned with such things.
> The reason the draft makes a negative statement about > fragmentation/reassembly is that there is a measurable issue with > fragmentation/reassembly. To pick a data point, Geoff Huston has been > measuring a blogging in the past year or two about MTUs observed in DNS root > and resolver servers, and the reduced reliability of DNS as a result of > dependence on IP fragmentation. Fernando Gont has been doing experiments > measuring the impact of IPv6 extension headers in transit, one of which is > the fragmentation header. Another point, although I refer to general > commentary rather than data, is that PLPMTUD is not generally used for some > reason, and PMTUD - and packet fragmentation in general - is frequently > disrupted by filters. That is the reason that, as you state, fragmentation is > not generally useful on packets that will cross the open Internet. The issue > with saying it can only be used in a confined space is that the application > generally doesn't know the location or path that its packets will use. I'm thinking of a certain banking configuration that has been discussed in IETF circles in the past couple of years that has multiple layers of load balancers and firewall-equivalents within a single data center. The application simply doesn't know whether IP fragmentation will be useful in a given environment. If it is forced to make a non-fragmentation solution available as well as a fragmentation-based solution, the questions arise how it distinguishes the cases and why it really needs both. > My fundamental concern is that the wording in the draft generally recommends against the use of a standard protocol feature. Not because the protocol is broken or the feature has been obsoleted, but because some implementations are non-conformant with the protocol standard. I'm worried that this sort of recommendation and the rationale for it will be extrapolated to recommending against use of other standard features like extension headers (which you referred to above), use of any protocols other than TCP or UDP, or even the use of IPv6. Tom > So I'm really looking for alternative text that makes the point but gives > people the wiggle room they need to be comfortable. Happy to discuss by > phone/video if that's useful. > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
