Subject: Re: Intentional Host Reordering of TCP Fragments

From: "Jamal Hadi Salim" <[email-masked]>
Date: Fri, 16 Jun 2000 10:02:11 -0400 (EDT)

On Fri, 16 Jun 2000, Seddigh, Nabil  wrote:

> Jamal Hadi Salim writes:
> >
> >Linux's "intentional packet re-ordering" of fragments is because that
> >is more efficient for Linux to do 
> >
> 
> I guess I had already heard this opinion from you ;)
> I was also hoping to hear opinions from other folks 
> who have been involved in development
> of the TCP/IP standards etc....

Indeed, but: its only fair that other people hear these opinions as
well.

You are doing layer violations and expect systems that conform to
layering to adjust to your sins.
That the philosphical dilema.

> Seems to me that if network reordering is to be discouraged
> then the same principle should apply to end-hosts. Seems
> inconsistent to encourage network devices to avoid 
> reordering yet allow end-hosts to reorder.
 
I think maybe this is going out of the scope of tcp-impl so i am
re-directing it to end2end

cheers,
jamal

---

From: "Howard Berkey" <[email-masked]>
Date: Fri, 16 Jun 2000 14:24:43 PDT

Doing what Linux does re: transmit order of the fragments is perfectly 
valid and makes sense.  It also has no bearing on the earlier 
discussion about out-of-order segments.  Recieving frags out of order 
in IP does not imply anything about the order segments are received by 
TCP.

Howard

---

From: Bob Braden <[email-masked]>
Date: Fri, 16 Jun 2000 23:21:13 GMT

*> From [email-masked] Fri Jun 16 15:39:17 2000
  *> Subject: Re: Intentional Host Reordering of TCP Fragments
  *> To: [email-masked] (Bob Braden)
  *> Date: Fri, 16 Jun 2000 22:55:25 +0100 (BST)
  *> Cc: [email-masked], [email-masked], [email-masked]
  *> In-Reply-To: <[email-masked]> from "Bob Braden" at Jun 16, 2000 08:37:45 PM
  *> X-Mailer: ELM [version 2.5 PL1]
  *> MIME-Version: 1.0
  *> Content-Transfer-Encoding: 7bit
  *> From: Alan Cox <[email-masked]>
  *> Sender: [email-masked]
  *> Precedence: bulk
  *> X-Lines: 16
  *> 
  *> > 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.
  *> 
  *> So you want to do two passes over the data then send not one pass over the
  *> data sending as you go.
  *> 

I don't think I said two passes, but this is not the time/place to
have this discussion (AGAIN!)

Bob

---

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 16 Jun 2000 19:49:08 -0400 (EDT)

Alexey,

>
>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.
>

Sorry. I should have said "reverse ordering" ;) It is not 
just 1 or 2 packets reordered but *all* pkts in a fragment
family with same ip_id. The pkt with the L4 information
is actually sent after all other pkts in that fragment family.

>
>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.
>

Agreed! However, if you are doing the L4 classification 
at the network edge (eg. enterprise gateway) then the 
probability that the network causes pkt with fragment_offset 0 to 
arrive after other fragments is not that high. L4 Classification
schemes can accurately classify fragments in this case.

When the end-host intentionally reverse-orders fragments,
it puts the nail in the coffin for the classification scheme -
it ensures *ALL* fragments that need L4 classification will be 
incorrectly classified. 

Best,
---
Nabil Seddigh
[email-masked]