Having larger MTUs and machinery around it so it works reliably also with the installed base is an applaudable goal. Not sure if an IETF document can convice the IEEE to spec this out, but it is definately worth trying.

Am 06.11.24 um 16:09 schrieb Matt Mathis:
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
- The L2 MTU specification is "owned" by the IEEE
     - Overriding the default MTU almost certainly violates parametric assumptions in the design      - There is not a conformance specification for jumbo, and interoperability is not guaranteed      - Ad Hoc jumbo testing is not robust because it is subject to "false pass" test results           - e.g. clocks that are good enough at some temperatures may not be at other temperatures

- Alarming discovery when PLPMTUD [RFC 4121] was almost done
     - we encountered a device (bgic)  that ran error free at 1500B, but showed 1% loss at 4kB

- Workaround text in the top of Section 4 of RFC 4121

    All links MUST enforce their MTU: links that might
    non-deterministically deliver packets that are larger than their
    rated MTU MUST consistently discard such packets.

    - This makes sense to computer scientists and protocol engineers, but it is actually out of scope for the IETF

- Goal is organizing yet another attempt to coax the IEEE to address this issue.

Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
-------------------------------------------
Matt Mathis  (Email is best)
Home & mobile: 412-654-7529 please leave a message if you must call.


_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur

_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org

Reply via email to