On Fri, Aug 3, 2018 at 12:48 AM, Mikael Abrahamsson <[email protected]> wrote: > On Thu, 2 Aug 2018, Tom Herbert wrote: > >> This leads to driving everything down to only support the least common >> denominator. Problem is that we can never move things forward if everyone is >> bound to LCD. > > > I don't understand why people think this is what I am saying. > > Car engines have "limp mode" when things go wrong. This is a restricted mode > that gets you home, works much worse, but at least doesn't leave you > stranded. I am saying applications should have the same. > > I've kept saying "Networks must support ip fragmentation properly. > Applications should still work somewhat when it doesn't". > > Så relying on fragmentation and falling over when it doesn't work is not a > good strategy to recommend to application developers. > You could say the same the thing about extension headers, SCTP and DCCP, and even IPv6 itself since it still doesn't work everywhere. The only protocols an application can _rely_ on working is TCP over plain IPv4. That is current LCD. If the advice is that applications only use protocols they can rely on, then Internet is stuck in time.
IMO, there should be a way for applications to use "alternative" features and protocols with a fallback mechanism if necessary. For instance, if the application had a priori knowledge that all nodes in a path supported fragmentation, then there should be no issue with it using fragmentation when sending on that path. Applying the car analogy, if I look at a map and don't see any unpaved roads on the route to my destination, then I can leave my four wheel drive all terrain vehicle at home and take my Ferrari instead. I think that a generalization of "Happy Eyeballs" might be a solution that discovers and maps what features and protocols work on what paths. Per the draft at hand, I think the advice to try to avoid fragmentation is practical under the current circumstances. However, I think that recommendation needs to be heavily qualified and scoped appropriately. A general statement that applications shouldn't rely on fragmentation cannot be interpreted as acceptance of non-conformant implementation or as a free pass that middleboxes don't need to fix there stuff. Tom > > -- > Mikael Abrahamsson email: [email protected] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
