Re: [RPRWG] More comments on preemption
Pankja,
Comment on your last statement, Low Bit Rate doen't mean Low Latency.
William Dai
----- Original Message -----
From: "Pankaj K Jha" <pkj@xxxxxxxxxxx>
To: "Denton Gentry" <denny@xxxxxxxxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Friday, April 13, 2001 10:49 AM
Subject: Re: [RPRWG] More comments on preemption
>
> Fully agreeing with Denton, there are many situations that need large
> frames. Maximum packet sizes for SAN networks is also larger than Ethernet
> MTU. IP over FR or ATM (rfc2225) specifies 9K. Especially for SAN,
allowing
> larger frame size for RPR would immediately allow RPR to be used for SAN
> applications over metro/WAN areas. Routers/aggregators don't need to
> fragment a sector data before sending over to RPR network.
>
> Consider an RPR ring providing TLS and/or aggregation services on a metro
> ring: people could connect their LAN, SAN, and WAN equipment without
> worrying too much about fragmenting packets. SANs (a large growth segment)
> will be able to operate across a wider area using RPR without any
> performance degradation, for example.
>
> A need for preemption due to jitter/latency fears is unfounded. I don't
know
> of any application where a few microseconds (even a few tens of
> microseconds) will make a huge difference. Should there be networks where
> this does become a big issue, routers can always negotiate a smaller MTU.
>
> And, at lower rates everything runs at a lower rate (including
> high-priority traffic) so there should not be an extra concern for
latency.
>
> -Pankaj
>
> 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.
>
>