Re: [RPRWG] More comments on preemption
I didn't mean that either. The point is that (1) at lower speed rings the
application needs are also different - these applications are low-speed type
operations (for instance DSLAMs aggregating users and terminating at OC-3), and
(2) when latency does become an issue for VoIP in those networks, MTU can always
be lowered through negotiation.
For instance, larger MTUs will be used in high-speed SAN applications where
network capacity is OC-12/48/192+ while smaller MTUs will be used in lower-speed
networks. Systems will choose an MTU depending on their tolerance level, MAC
shouldn't limit it. Systems would know the consequences of their large MTU size
and they will act accordingly. By the time RPR becomes a standard, high speed
networks will be common at a lot of places.
-Pankaj
William Dai wrote:
> 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.
> >
> >