| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
About 3-4 days ago there were a few email exchanges on IETF mailing list about SONET/SDH 50msec (and why of it), recovery, latency and other transport requirements for other optical networks. These emails also had links for reference materials on the topics. Maybe I'll forward some of those exchanges to RPR mailing list so we can get some more backgrounder for further discussions on the topic.
Regards,
Pankaj
Harry Peng wrote:
At a node with large ring BW this is not an issue.
A typical packet may traverse several RPR rings and some other network cloud from its source to research its destination. It is about 45 ms for U.S. cost to cost propagation delay.Are you bounding the Ring propagation delay to the order of tens of milli-seconds?
regardless of number of nodes?...Harry
-----Original Message-----
From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
Sent: Friday, April 13, 2001 1:50 PM
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.