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

[Alexandre Petrescu <[e-mail]>]

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