Hi Joe! Inline On Wed, Nov 6, 2024 at 7:34 AM to...@strayalpha.com <to...@strayalpha.com> wrote:
> Hi, Matt, > > On Nov 6, 2024, at 7:09 AM, Matt Mathis <matt.mat...@gmail.com> wrote: > > The deck is pretty much self explanatory and only 11 slides. Networks are > Analog but MTU is not > <https://datatracker.ietf.org/meeting/121/materials/slides-121-intarea-analog-blockers-to-wide-employment-of-jumbo-mtus-in-the-production-internet-00> > > Key points: > - At L1, Ethernet is really analog > - IEEE specifies waveforms, thresholds, tolerances and testing > methodology > - L1 MTU limit is derived from non-digital parameters, such as clock > stability > > > Ethernet was self-clocking (still is, electrically - Manchester encoding), > so there’s no reason clock stability would come into play. > [MM] This is true for all modern implementations, but it was not true for the earliest Ethernet. The PLL only ran on the preamble, and the clocks fee ran during the data. i.e. the ability to decode the last bit depends on the clock stability and MTU. The trouble is these older implementations are still technically in spec. One of the barriers to standardizing jumbo is that the IEEE is extremely reluctant to change standards in ways that cause currently deployed devices to fall out of spec. [MM] There is not a general way to discover what MTU assumptions might be baked into the L1 design. I agree that they are far less likely with modern high speed encodings, however older designs/assumptions can absolutely be in spec. The minimum size was (64 bytes) based on trying to “capture” the largest > shared-media segment with a signal to ensure no others were transmitting; > as speeds increased, the length of that broadcast segment decreased until > it effectively disappeared with switched (non-broadcast) Ethernet. I would > expect the largest packet was limited by a combination of memory cost and > the desire to avoid blocking the segment too long - both arguably digital > driven, not just analog. > [MM] Your MTU observation applies to completed products, but not to NICs that DMA directly into cellified memory. e.g. If memory is carved into 512B pages, it would be reasonable to expect to be able to DMA arbitrary sized packets directly into memory. [MM] However this would potentially cause a political/process problem for the IEEE: Vendors that use designs that can't chain buffers (e.g. default to 1500B fixed size buffers) are at a substantial disadvantage in the market and are likely to object to other vendors standardizing jumbo. This might be the real barrier to a jumbo standard. > > > But, FWIW, why not ask Bob on the Internet History list?? > [MM] Excellent idea! > > Joe >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
