Subject: Re: Intentional Host Reordering of TCP Fragments

From: Bob Braden <[email-masked]>
Date: Fri, 16 Jun 2000 20:37:45 GMT

*> 
  *> I apologize, the word "reordering" applies to the cases
  *> when some order ever existed. 8) There is no order for fragments,
  *> but that one, which sending host generated.
  *> 

This statement is, at best, misleading.  Of course there is a natural
order for IP fragments, big-endian like all other network transmission!

It seems curious to me that an OS can create the fragments in reverse
order without having all the segment in a buffer at one time, since
applications certainly do not deliver bytes to the kernel in
reverse order.  And if they are all there at one time, you can
compute the checksum over it.  Oh, well.

The Linux approximation to a trailing checksum is only the latest
skirmish in the long-running war over whether TCP trailing checksums
would really help performance (assuming lack of brain damage in
hardware and software).  One of the early battles in that war was the
Berkeley trailer system (BSD was the Linux of the 1980s, remember?),
and community consensus eventually killed it as a Bad Idea (see RFC
1122 section 2.3.1).  The battle recurs every couple of years on some
large mailing list.  No one is every convinced, but the consensus
usually seems to emerge that TCP trailing checksums are not very
useful for performance.

  *> 
  *> 
  *> > BTW, if you have an algorithm that allows you to do
  *> > 100% accurate Layer-4 classification (without caching) 
  *> 
  *> 100% accurate algorithm, which classifies IP packets using keys
  *> contained in payload, does not exist, cannot exist and must not exist.
  *> It is in contradiction with basic principles of IP.

Yes. Protocols that need MF classification had better not do any IP
fragmentation.  EG the Int-Serv specs say that explicitly, and they
provide mechanisms to inform the sender of the E2E MTU so it can avoid
fragmentation.

None of this has much to do with TCP, so this discussion is on
the wrong list.

Bob Braden

  *> 
  *> If such pseudo-router really wants to do this, it must:
  *> 
  *> 1. Be sure that no other paths from the source to the destination exist.
  *> 2. Gather all the fragments before doing any decisions. The situation,
  *>    when different fragments get different QoS must be excluded
  *>    __completely__, otherwise this QoS loses a sense.
  *>    BTW, moving closer to the subject, only after this it should
  *>    issue them in the same order, which they were received in. 8)8)8)
  *> 
  *> Alexey
  *>

---

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

> compute the checksum over it.  Oh, well.

So you want to do two passes over the data then send not one pass over the
data sending as you go.

L1 cache misses are expensive. I want to touch the data once since Im forced
to touch it.  With UDP it can be a big win because there are plenty of
cpus with small caches especially the embedded and performance sensitive ones.

We've been doing it for I think 4 or 5 years now

ALan