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

[Alexandre Petrescu <[e-mail]>]

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