[e2e] packet reordering in OC 48 links

[Cannara]

Omygod, there are links to the past -- I feel like Tom DeLay (not)!  I'll
repeat:  "The designers of most NPUs considered reordering a no-no, so
provided built-in hardware to track flows, as identified in simplest form by
tuples, like: input-interface, port/channel, IP details, etc."  So, packets
are expected to arrive on multiple interfaces, yet be kept in the same flow,
as for instance, a Cisco router will do if set to use parallel T1s in a
certain forwarding mode.  Any router that can't uniquely associate every
packet in a stream for output on the right interface, regardless of input
interface, isn't worth buying.  

And, if link speed challenges router vendors, use slower interfaces -- we can
get a lot of performance back by simply fixing the Internet to do what it
always should have done, to avoid spam, etc.

Alex

Nischal Piratla wrote:
> 
> Alex,
> Thank you for the pointer.
> However, I am still concerned about a couple of things:
> 1. Will we be able to continue the handling of the order of packets in
> routers, with the known trends of network speeds?
> 2. As you mentioned in your posting earlier:
> http://www.postel.org/pipermail/end2end-interest/2004-August/004234.html
> Will we still see reordering with multiple interfaces on NPUs?
> 
> - Nischal
> 
> >===== Original Message From cannara at attglobal.net =====
> >The problem has been solved by some network-processor vendors for a few years
> >now.  For example, see the specs for the IQ2200 by Vitesse, that's been used
> >to handle 4 parallel, FDX 1Gb/s ports in equipment by various manufacturers,
> >including Cisco.
> >
> >Alex
> >
> >Nischal Piratla wrote:
> >>
> >> Govind,
> >> We feel that it is quite reasonable to see such high amounts of reordering.
> In
> >> fact, we are working on this very problem.
> >>
> >> Most of the reordering that occurs within the routers is countered by
> either
> >> input reordering (packets of same flow are added to same queue) or output
> >> reordering (packets from same flow are tagged at the input, and are
> collected
> >> to be sent in order at the output). However, due to increasing table sizes,
> >> difference in the rates of increase in network speeds vs. the computing
> >> speeds, etc., higher parallelism is inevitable and the methods stated above
> >> may not be useful. We discussed a little more about it in our recent paper:
> >>
> >> http://lamar.colostate.edu/~nischal/Papers/Networking2005_RD.pdf
> >>
> >> Also, to understand the amount and extent of reordering, we suggest
> 'Reorder
> >> Density' metric that comprehensively illustrates reordering. There are perl
> >> scripts and Java applets readily available for the same on this site:
> >>
> >> http://www.cnrl.colostate.edu/packet_reorder.html
> >>
> >> - Nischal Piratla
> >>
> >> >===== Original Message From "S.Govind" <sgovind at hpc.serc.iisc.ernet.in>
> =====
> >> >hi all
> >> >
> >> >
> >> >I have currently programmed the intel IXP 2400 Network Processor for IPv4
> >> >forwarding.
> >> >Iam able to support line rates up to 3 Gbps (without any QoS provisioning)
> >> >but an area of concern is the reordering, i obtain reordering up to 33%
> >> >(ie: 33 % packets are reordered )for a link with 4000 flows a second
> >> >each TCP flow of size 6.4 KB and 14% reordering for flow size of 640 B.
> >> >
> >> >The packets are assumed to be arriving at a constant interval of time and
> >> >of constant size (64 B ), this assumption is used for DoS attacks.
> >> >
> >> >I am novice in networking, i have a few queries regarding the above
> >> >results.
> >> >
> >> >Are these numbers (reordering) indicative of current OC 48 links,
> >> >
> >> >
> >> >Any comments and/or suggestions on the above  is most welcome
> >> >
> >> >Thanking You,
> >> >Govind
> >> >
> 
> /******************************************
> Research Assistant
> Computer Networking Research Laboratory
> Department of Electrical and Computer Eng.
> 1373, Colorado State University,
> Fort Collins, CO 80523 USA
> http://www.cnrl.colostate.edu
> http://lamar.colostate.edu/~nischal
> *******************************************