Subject: re: Classifying fragments

From: "Nabil Seddigh" <[email-masked]>
Date: Mon, 25 Oct 1999 13:12:35 -0400 (EDT)

Nick,

Consistent classification of fragments based on layer 4 and above
information is the responsibility of the classifier. It will probably
require  some kind of flow manager as well - to track flows etc.

As far as I can see there is no way of classifying fragments
consistently without maintaining some form of state. 

One approach is to classify based on the first non-fragmented packet
(this packet will have the necessary layer 4 port numbers) in  a flow
and  then use this result for the rest of the packets in the flow.

Another approach is to classify based on the first packet in a family of

fragments (this packet will have layer 4 information). This result can
then be applied against the remaining packets in that 'family' of
fragments. The association between the packets is via the ip id field.
Of course if the second or subsequent packet in a  'family' of fragments

arrives before the first packet (due to reordering prior to this node),
you have at least three choices: (i) buffer these packets (very bad) or

(ii) classify them anyway (with wrong information since there's no L4
info) or (iii) give them some default packet marking defined by the
system. None of the choices seem particularly appealing :)

Regards
Nabil

>
>The Conceptual Model for Diffserv Routers defines standard method for
>classifying IP packets using filters. This method may interpret
>information  in the protocol header (e.g. TCP/UDP port #), which is not
>available in IP fragments. My question is: without saving state, how do
>we ensure that all the fragments (including fragment 0) are classified
>consistently?
>
>--
>==================================
>Nicholas WIlliamson
>[email-masked]
>
>ECI Telecom
>1201 Cypress Creek Road
>Ft Lauderdale, FL 33309
>(954) 772-3070
>==================================
>
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Oct 1999 09:17:11 +0200

> >>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
> 
>     Brian> Michael Richardson wrote: ...
>     >> This suggests that non-initial fragments should get BE 
> marking. That's
>     >> the penalty for not doing PMTU discovery. I think this 
> is fair, and
>     >> may finally push PMTU issues to the front.
> 
>     Brian> Obviously that is the default solution, and it has 
> the property
>     Brian> that it may well cause the tail of packet N to be 
> delivered after
>     Brian> the head of packet N+1 - a performance disaster, 
> but not a change
>     Brian> in the formal default service.
> 
>   But, like I said: if you wanted performance, you'd take 
> care to do PMTU
> properly, and you'd beat on your "security" people who think 
> that all ICMP
> packets should be filtered out.

I just thought I'd let you know: Path MTU discovery could also
be done using PTP, which is described at
http://www.ietf.org/internet-drafts/draft-welzl-ptp-01.txt
This needs router support, though; if only a few routers support
it, the result could at least be used to find a PMTU discovery
starting point and shorten the process.

BTW, feedback on PTP is appreciated!

Regards,
Michael Welzl