RE: [RPRWG] More comments on preemption
The payload/services over RPR that have the same
requirements as SAN are possible and RPR is expected
to be attractive solution for that. I have no public
data points to back this up though.
Independent of SAN, 9K Jumbo, whether or not is blessed
in the standard, will find its way to RPR just like Ethernet.
Also I agree w/ other e-mail tread that .17 is free to set
any MTU value it wants to (not that I am encouraging an
arbitrary value).
.3 has been 1518 until 802.3ac changed it to 1522.
.5 MTU is 4550 @ 4 Mb/s and 18.2K @ 16 Mbit/s.
.4 MTU is 8208
.6 MTU is 9188
.17 MTU discussion has been on two values, 15xx and 9K at any speed.
Yong.
============================================
Yongbum "Yong" Kim Direct (408)922-7502
Technical Director Mobile (408)887-1058
3151 Zanker Road Fax (408)922-7530
San Jose, CA 95134 Main (408)501-7800
ybkim@xxxxxxxxxxxx www.broadcom.com
============================================
-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
Behalf Of Devendra Tripathi
Sent: Friday, April 13, 2001 2:48 PM
To: Pankaj K Jha; Denton Gentry
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] More comments on preemption
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.
>
>