Alex, it is true that we are stuck with "minimum/maximum" double-speak. So, since the beginning of time we have had:
minMTU (minimum maximum transmission unit) minMRU (minimum maximum reassembly unit) and now: minMPS (minimum maximum payload size) But, the latter is really not a new IP term because the IP layer never sees it; it is only an adaptation layer term. Fred > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com] > Sent: Thursday, December 09, 2021 2:55 AM > To: Templin (US), Fred L <fred.l.temp...@boeing.com>; int-area@ietf.org > Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact > features do we want from the Internet? minmax > > EXT email: be mindful of links/attachments. > > > > > > Le 08/12/2021 à 18:09, Templin (US), Fred L a écrit : > > 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. > > MPS - Maximum Payload Size - is a new term in IP? > > minMPS sounds not perfect. If the goal is to have a minimum size, then > it should be minPS. > > I am not nitpicking. > > I am just in search for a term that designates the minimal IP packet. > This term is useful on links for IoT on which IP runs. For that, the > term 'MTU' does not apply because 'M' means maximum. The term 'minimum > MTU' does not apply either, because MTU itself is a characteristic of > expressing an upper extreme of a characteristic of a link and not of the > packet. It is not because the minimal MTU of IPv6 is 1280 - so to speak > - that one cant transmit 321bit-sized packets on IPv6. > > If someone looks at new features for the new Internet and talks about > jumbograms and infinite packet sizes: that's the circuit! > > Comparably, a new feature for the new Internet could be minimal sized > but very numerous packets. 321bit-sized IPv6 packets on links at 10 > petabit/s is for the new Internet. > > Or maybe the new Internet holds for a 'continuum' between these two: > from infinitely large packets to infitinely small packets. > > In an infinitely-large packet Internet the energy consumption would be > almost zero because we start measuring but we never end, whereas with > smallest packets it would be much higher. > > Alex > > > > > 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
