Sorry Alex, I spoke imprecisely. In ATM, there is one fixed cell size but for heterogeneous Internetworks the 576 determines only a lower bound for cell sizes - not an upper bound. In ATM the fixed cell size is 53 octets (5 octets header; 48 octets payload), but for heterogeneous Internetworks we need to leave a lot of extra room for headers. So we define a "minimum Maximum Payload Size (minMPS)" of 400 octets. That leaves a generous 176 octets for encapsulation headers, which will most often not be fully consumed due to header compression.
Again, this defines only the minimum MPS; larger MPS values can be discovered through path probes, or can be set optimistically under the risk of encountering unexpected size restrictions. Fred > -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Alexandre > Petrescu > Sent: Wednesday, December 08, 2021 6:16 AM > To: int-area@ietf.org > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? minmax > > The advantage of talking 'minimum cell size' (MCS?) instead of 'maximum > transmission unit' (MTU) is in that it fits better to a preceding > 'minimum' qualifier. > > A 'minimum MTU' term expands to a 'minimum maximum transmission unit'. > That construct can be ambiguous to an implementer. Is it a 'minimum > transmission unit'? Or is it the smallest of all MTUs of all link designs? > > On another hand, a 'minimum minimum cell size' is clearly just a minimum > cell size, just further accentuated in its minimization: a 'minimum > minimorum' if one wishes. Where MCS is 576 a minimum MCS in IPv6 could > be 41: 40 bytes of header and 1 byte of payload. Or maybe 40 if there > is no payload. Or maybe 321 bits if there is just one bit of payload > (an on/off switch or flag in IoT speak). > > Alex > > Le 08/12/2021 à 02:38, Templin (US), Fred L a écrit : > > This conversation is missing some fundamental points – really the > > most important > > > > points – which are the minimum sizes guaranteed to work everywhere. > > For IPv6, > > > > the minimum MTU/MRU are 1280/1500. For IPv4, they are only 68/576 but > > since > > > > the IPv4 network supports fragmentation we can nominally designate > > the IPv4 > > > > minimum MTU as 576 also if we clear the DF bit. It means that, > > without probing > > > > or having some divine knowledge of paths that have not been > > previously visited, > > > > the ONLY sizes guaranteed to work are 1280 for IPv6 and 576 for > > IPv4. > > > > Now take the case of Multinet where a path may traverse multiple > > concatenated > > > > IP networks of arbitrary IP protocol versions - remember “Catenet”? > > Since there > > > > may be no advanced knowledge of network IP protocol versions, the > > most we can > > > > absolutely and for sure count on across the entire path is 576. > > > > What this gives us is not the **maximum packet size**; instead, it > > determines the > > > > **minimum cell size**. We know that a 576 cell will traverse all > > paths, so we never > > > > send a non-final cell smaller than this (which might trigger a tiny > > fragment alarm). > > > > But, we can certainly send packets larger than the path MTU - > > **much** larger in > > > > many cases. And for paths that support them, we can also send Brian’s > > jumbograms. > > > > Speaking of jumbos, on a different list I made a point about how this > > all harkens back > > > > to RFC1149 and RFC6214. But nowadays, we can imagine substituting a > > memory stick > > > > for the slips of paper with whitestuff and blackstuff and those avian > > carriers will > > > > transport jumbos just fine. Not quite unlimited MTU, but close > > enough. > > > > Fred > > > > > > _______________________________________________ Int-area mailing > > list Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
