Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet? minmax

["Templin (US), Fred L" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, December 09, 2021 2:55 AM
> To: Templin (US), Fred L <[e-mail]>; [e-mail]
> 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:[e-mail]] On Behalf Of Alexandre Petrescu
> >> Sent: Wednesday, December 08, 2021 6:16 AM To: [e-mail]
> >> 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 [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/int-area
> >>
> >> _______________________________________________ Int-area mailing
> >> list [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area