Re: [RPRWG] More comments on preemption
> I agree with the analysis, here. My thinking is that jumbo frames
> on Ethernet will be more used in SANs rather than LAN/WAN area.
Actually, people are using (non-standard) jumbo frames on
LANs as well. Letting the software process 9K at a time instead
of 1.5K increases performance in almost all scenarios.
However, for 802.17 we will not be defining how jumbo packets
can be passed from an RPR ring to an ethernet. We could only include
such a section in the spec if there were a jumbo frame option defined
for 802.3. There isn't a jumbo frame option in 802.3, a jumbo frame
option is not likely to spontaneously appear in 802.3, and I think
the RPR group has better things to do with its time than lobby 802.3
to add one.
RPR should support larger than 1500 byte frames for three reasons:
1. It allows service providers to encapsulate ingress packets within
their own headers.
2. It allows end-stations sitting on the RPR ring to converse using
large MTU packets.
3. It allows systems builders to easily traverse packets from RPR to
their non-standard, proprietary, large MTU networks which happen
to look a lot like ethernet.
Supporting #1 requires a moderate increase in the frame size. 2K has
been suggested, to leave room for one or more encapsulating IP headers.
Supporting #2 requires a larger increase in the frame size. 9K has
been
suggested because current computer systems use 4K and 8K page sizes.
Supporting #3 requires at least the frame size as that non-standard,
proprietary net. Unfortunately there is little agreement among systems
vendors of what that should be. Some use 4472 bytes (a la FDDI), some
advocate 9000 bytes, some 9216 bytes (a la ATM LANE), and I'm sure there
are more.