Date:   Sun, 15 Oct 2000 23:31:10 +0200
From:   bert hubert <ahu@ds9a.nl>
To:     netdev@oss.sgi.com
Subject: Re: packet reordering
Message-ID: <20001015233109.A10818@home.ds9a.nl>
Mail-Followup-To: netdev@oss.sgi.com
References: <20001014185419.A8295@home.ds9a.nl> <200010151919.XAA23839@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200010151919.XAA23839@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sun, Oct 15, 2000 at 11:19:16PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Content-Length: 2151
Lines: 62

On Sun, Oct 15, 2000 at 11:19:16PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> >  this: 2, 1, 4, 3, 6, 5. The problem is that this confuses TCP/IP.
> 
> It does not really, provided this tcp/ip is linux-2.4 tcp/ip. 8)8)
> 
> Yes, of course, it is problem. That's why I did not recommend
> to use per-packet balancing and to use multipath routes instead,
> when it is possible.

For people who want to speed up single tcp/ip sessions, it's not possible. I
have noted in the HOWTO however that Linux is 'smart' about this reordering.

> It is possible, of course. And no doubts, it will be useful.
> Only not ingres qdisc, I think, but netfilter plugin. ingres
> qdisc is netfilter plugin itself.

Ok.

> But it will not work very well. You will not able to answer
> to the question what is this "some latency". If you balance modem links
> you will have to select "some latency" bw*dev_queue_len+<some good delta>.
> It is big number.

It may not be generally useful, true. However, if we equip the reordering
queue with some brains, it might just work. For example, it might have a
fair chance of detecting the 'immediate-next' packet, and send that
directly. For example

2 1
   -> send 1 2, sequence matches

If it doesn't detect such a match, just send after n ms. I'm no router
expert, just thinking out loud.

> Actually, link specific encapsulation (sort of gre) could be used
> to preserve order on link. Seems, MPPP even does this.

This would mean a smarter equaliser and 'merger', but it could be done. I
think this would need a netfilter plugin as well, because I don't expect a
queue to modify its packets?

> > # tc qdisc add dev eth0 handle ffff: ingress
> > RTNETLINK answers: No such file or directory
> > 
> > I think I included everything needed in the kernel.
> 
> I do not know, honestly. Ask Jamal.
> "Jamal Hadi-Salim" <hadi@nortelnetworks.com>

Ok, thanks. I continue to be amazed by the wild possibilities of Linux
routing. 

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet