Hi Ole, > -----Original Message----- > From: otroan@xxxxxxxxxxxxx [mailto:otroan@xxxxxxxxxxxxx] > Sent: Tuesday, February 14, 2017 10:33 AM > To: Stewart Bryant <stewart.bryant@xxxxxxxxx> > Cc: Templin, Fred L <Fred.L.Templin@xxxxxxxxxx>; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; gen-art@xxxxxxxx; 6man WG > <ipv6@xxxxxxxx>; ietf@xxxxxxxx; draft-ietf-6man-rfc1981bis.all@xxxxxxxx > Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04 > > Stewart, > > > *If* you care about packet loss, then your only option is to probe the path with with > > synthetic data that exactly mimics the live data, or not to probe at all and live > > with the 1280. As I said 1280 is pretty close to 1496 which is all most networks > > will give you in practice. > > Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of the minimum MTU was to give space for tunnel headers > (1500-1280). But, if non-tunnel links set a 1280 MTU which is perfectly OK with the standard then there is no space for headers. Given the issues with classical PMTUD then (plus the non-applicability of RFC4821 for tunnels) the only solution for tunnels is fragmentation. I'll let Joe step in if he wants to. Thanks - Fred > > When I think about the people asking for fast re-route to minimise packet loss, it seems > > very strange to deliberately induce loss to try to stretch the MTU by 15%. > > Please show the data that there is significant loss. The measurements I have found has not shown that. > If not, then let's please leave that argument on the shelf. > > (And please don't read me wrong, I think we should get DNS fixed, that we should fix the IP tunnelling protocols, and that we should > get IP fragmentation deprecated). > > But right here, right now. PMTUD is for many problems the only solution on the table. > We as a community can choose not to elevate the standard of course, and that will of course not have any big consequence. > Are you afraid that elevating 1981, will hinder people from working on new and better solutions? > > Best regards, > Ole