Re: [RPRWG] More comments on preemption
Ajay:
It's a lot easier to sort out once you list frame sizes for other protocols
and applications. Ethernet just happens to be the frame format we are going to
be using, but there is nothing that precludes a larger frame size. I have no
idea why hardware cost will go up if the MAC supports a larger frame size.
Maybe the transit/transmit buffers inside the MAC, but we're talking about
20-30K of memory (maybe more if deeper buffers are required) for that. This by
itself is not a major cost point. Other than that everything else would fall
to the system side.
There is nothing in RPR that magically should come to 1518 bytes. We're
talking about NBMA networks, not CSMA/CD - packets go from one node and end up
at another node before being sent out to the third node (through cut-through
or store-and-forward). And, if any network cannot tolerate larger MTU sizes,
nodes can always negotiate lower MTU - this is fairly standard.
I know Windows & Unix platforms have been supporting jumbo frame sizes for
about 2+ years now, there was an article in Internet Week giving performance
figures for OSes for jumbo packets. There is an IETF draft on jumbo packets
for Ethernet networks (I don't know the status of the draft; I can find and
send a copy).
The 1518 byte size has a historic background behind it, and we need to support
it but we need to move forward and "allow" for much larger sizes so
applications such as SAN can readily use RPR without much fragmentation. We
need to move with times and allow for developments. We definitely are
maintaining packet formats, so that should keep Ethernet happy.
Regards,
Pankaj
Ajay Sahai wrote:
> Denton,
>
> I think that the group will be much better off if we can define a MAC
> which reduces frame loss rather increase frame size. Of course this
> relationship is true only for TCP traffic. But since that is a significant
> part of the
> traffic we should seriously think about this tradeoff.
>
> Increasing frame size will increase h/w costs and complexity without
> probably that much benefit.
>
> Regards,
>
> Ajay
>
> Denton Gentry wrote:
>
> > > 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.