Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, October 10, 2016 10:29 AM > To: t.petch <[email protected]>; Templin, Fred L <[email protected]> > Cc: [email protected] > Subject: Re: [Int-area] Questions to draft-intarea-tunnels-03 > > Hi, Tom, > > > On 10/9/2016 3:05 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Joe Touch" <[email protected]> > > Sent: Saturday, October 08, 2016 12:24 AM > > > > > >> Hi, Tom, > >> > >> Thanks for pointing that out. I'll try to revise to make that easier. > >> > >> If you have any other specific examples, please let me know (either > >> on-list or directly). > > Joe > > > > How about > > > > ' o Tunnel internal MTU (TIMTU): the largest message that a tunnel > > egress can emit into a tunnel without requiring further > > fragmentation to reach the tunnel egress.' ? > > > > You may have to read it twice to see my confusion. > > Yes - that's a typo that should read as follows, which should be more clear: > > o Tunnel internal MTU (TIMTU): the largest message that a tunnel > ingress can emit into a tunnel without requiring further > fragmentation to reach the tunnel egress. > > > > More generally, I think that Fred's point is well made, that the > > terminology, particularly the abbreviations thereof - e.g. LMTU, TIMTU, > > TMTU, PMTU, ERMTU, RMTU - make the I-D harder to follow. > > The challenge is that it's nearly impossible to discuss these issues > without coining new terms because the existing ones are so poorly > understood in the context of layering. > > We generally care about many different MTUs: > - the largest IP packet that can traverse an IP path > this is NOT the path MTU, but rather the receiver reassembly MTU > we CANNOT transmit transport segments larger than the payload of > this IP E2E MTU > > - the largest IP packet that can traverse an IP path without needing > on-path fragmentation > this is the path MTU > it is critical for IP source fragmentation (or the packets won't > get there at all) > it's an optimization for transports that frag/reassemble (to > avoid source fragmentation) > > Neither of these has anything to do with the link MTU, which has similar > variants. > > As we keep discussing this issue, we've come up with various notions of > what these names could be. > > We could call these the: > IP transit MTU (defined as the source-to-dest MTU, but equal to the > IP receiver reassembly MTU) > IP path MTU (min of the IP hop MTUs) > IP hop MTU = link/tunnel transit MTU - link/tunnel overhead > > link (or tunnel) transit MTU (defined as source-to-dest MTU, equal > to link/tunnel receiver reassembly MTU) > link path MTU (min of the link hop MTUs) > link hop MTU = MTU of a single physical link > > I'm glad to revise if these are more clear.
IMHO, your draft is getting wrapped up with too many new acronyms for no good reason when simple English-language text would make things easier to understand. See Section 3.12 of 'draft-templin-aerolink' for simple and easy to understand text. In 'draft-templin-aerolink', there are only five acronyms: MTU - the MTU of the tunnel as seen by the IP layer MFU - the maximum fragment size within the tunnel MRU - the maximum reassembly size supported by the egress ENCAPS - the size of the encapsulation headers inserted by the ingress PTB - an IP Packet Too Big message Everything else is just simple English language, and does not need any other acronyms. Thanks - Fred [email protected] > Joe > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
