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
