Subject: Re: Intentional Host Reordering of TCP Fragments

From: "Narsimharao Nagampalli" <[email-masked]>
Date: Fri, 16 Jun 2000 07:01:56 -0600

QoS, Server Load Balancing Solutions, Filters  would be other examples where such a re-ordering would be a problem. 

I hope, the flow label in IPv6 will be some thing that will come to the rescue here. If the definition of the flow label can be driven to contain information from which the port numbers can be extracted, it would help L4 switches a lot.

-Narsi

Nabil Seddigh wrote:

> Recent discussions on this list focused on network
> devices reordering packets. How about an end-host
> that intentionally reorders some TCP packets?
>
> During testing of Packet Classification capability
> on for Diffserv-capable routers, one of my colleagues
> discovered that the Linux TCP sender intentionally
> reorders fragments - the pkt containing the TCP port
> number is the last pkt sent in a family (same ip_id)
> of fragments.
>
> The implication of such an implementation is that
> Layer-4 packet classification of fragments
> is virtually impossible - unless routers try to
> cache packets....not a desirable solution.
>
> Of course one could argue that most fragments on
> the net are UDP and not TCP but nonetheless:
> shouldn't end-hosts avoid intentional reordering?
>
> We checked out various RFCs and didn't find explicit
> prohibitions on an end-host reordering the pkts
> that it sends out.
>
> Best,
> ---
> Nabil Seddigh
> [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Fri, 16 Jun 2000 16:17:37 +0100 (BST)

> number is the last pkt sent in a family (same ip_id)

We don't reorder fragments we send packets in an optimised fashion.
Im suprised nobody else is doing this. Its common sense for any end host
that has to support software tcp checksumming

You cannot send the head of the packet until you know the checksum so we
build the fragments in reverse order. The last few fragments are leaving
the ethernet card before the first fragment and the checksum is computed
its very good for latency and its completely valid tcp/ip.

The only thing it broke was some older versions of the cisco pix and I believe
that is now fixed on the PIX.

Alan

---

From: Charles Esson <[email-masked]>
Date: Sat, 17 Jun 2000 07:16:17 +1000

I can see your point; and have no difficulty seeing you saved a pass over the data
for all but the first fragment, quite clever really, but it would make life harder
for those that believe layering can be ignored completely when handling data that
has been put on the wire ( and I think those in that school are crazy).

I however are in  the enforce layering absolutely school; and I  used objects when
doing my stack. The tcp ( and all other protocols) checksums are done by calling
the protocol object, so the call has to be done after you have filled in the
destination and before you fragment.  The concept of fragmentation is unknown to
the protocol object and it definitely doesn't get involved on putting the data on
the wire.

Mind you; just as I believe defragmentation belongs in the NIC, I believe
fragmentation belongs there also. This is possible if you treat the destination as
something the protocol layer can get with a call to the routing layer ( which you
have to do anyway as the destination address at least has to remain stable even if
the destination has multiple NICs and the path changes), and you do the protocol
checksum calculation in the protocol layer.

I however can see this is not how most people see the world. If the NIC deals with
fragmentation and defragmentation. then there is no penalty if you use 64k ip
packets, in fact things go better as you only have to deal with one header for
every 64k in the main CPU. If there is no penalty why would you spend anytime
working out the optimum packet size for the initial path.

Regards

---

From: Charles Esson <[email-masked]>
Date: Sat, 17 Jun 2000 11:00:35 +1000

This would make a lot more sense if I was talking about getting the source address
from the routing layer in a system that has multiple NICs.

Luckily  compilers convince me I was a fool years ago, so this is not a new discovery.