Re: [RPRWG] More comments on preemption
Devendra:
Not RPR on SAN, but SAN traffic going over RPR, and RPR providing transport
services for SAN applications. So you've SAN packets going over RPR, allowing
customers to access their central storage networks while interfacing to their
different offices over high-speed RPR rings (one or more of the nodes could be a
SAN access point). SAN, from the way it is going, is one of the highest growth
areas, as a lot of ASP are becoming software platform providers for centralized
computing and/or data storage.
-Pankaj
Devendra Tripathi wrote:
> Sorry for a tangent here. Is RPR on SAN a decent market ?
>
> Regards,
>
> Devendra Tripathi
> VidyaWeb, Inc
> 90 Great Oaks Blvd #206
> San Jose, Ca 95119
> Tel: (408)226-6800,
> Direct: (408)363-2375
> Fax: (408)226-6862
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
> > Behalf Of Pankaj K Jha
> > Sent: Friday, April 13, 2001 10:50 AM
> > To: Denton Gentry
> > Cc: stds-802-17@xxxxxxxx
> > 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.
> >
> >