Re: [RPRWG] More comments on preemption
Denton,
I think that the group will be much better off if we can define a MAC
which reduces frame loss rather increase frame size. Of course this
relationship is true only for TCP traffic. But since that is a significant
part of the
traffic we should seriously think about this tradeoff.
Increasing frame size will increase h/w costs and complexity without
probably that much benefit.
Regards,
Ajay
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.
begin:vcard
n:Sahai;Ajay
tel;pager:800-366-5546
tel;fax:845-731-2011
tel;work:845-731-2023
x-mozilla-html:FALSE
version:2.1
email;internet:Ajay.Sahai@xxxxxxxxxxxxxxx
title:Sr. Software Engineer
adr;quoted-printable:;;P.O. Box 1609,=0D=0A6th Floor, Two Blue Plaza,;Pearl River;New York;10965;USA
end:vcard