Subject: Classifying fragments

From: Nick Williamson <[email-masked]>
Date: Mon, 25 Oct 1999 11:19:52 -0400

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: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 1999 12:30:47 -0500

This is an open issue in the architecture (see RFC 2475, section 2.3.1).
Yet another reason why PMTU discovery is a Good Thing.

Note that the problem only arises for MF classifiers, i.e. only at
border routers. But that doesn't help if the packets were already
fragmented upstream of the border.
 
  Brian

Nick Williamson wrote:
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Steve Blake <[email-masked]>
Date: Mon, 25 Oct 1999 14:59:52 -0400

> we ensure that all the fragments (including fragment 0) are classified

This was discussed very briefly in RFC 2475, Sec. 2.3.1.  I don't know
of a solution other than logical reassembly of fragments.  This could
be discussed more thoroughly in the model draft and I am willing to do
this unless someone suggests a better document to discuss this in.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure             (919)468-8466 x232

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 1999 11:44:51 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> This is an open issue in the architecture (see RFC 2475, section
    Brian> 2.3.1).  Yet another reason why PMTU discovery is a Good Thing.

  A caution: PMTU discovery has not, I think, received enough emphasis
in other working groups. IPsec comes to mind. The method suggested in 2401
will work, but is somewhat ad-hoc and depends on a lot of hard state in
the gateways (there is already lots already, so this is not such a big deal).

    Brian> Note that the problem only arises for MF classifiers, i.e. only at
    Brian> border routers. But that doesn't help if the packets were already
    Brian> fragmented upstream of the border.
 
  As a maker of programmable MF classifier ASICs, we have been very concerned
about the amount of state required at border routers to deal with fragmented
packets. We have appealled to "standards", such as RFC2205, section 1.2
which suggests that:

      1.   It is necessary to avoid IP fragmentation of a data flow for
           which a resource reservation is desired.

           Document [RFC 2210] specifies a procedure for applications
           using RSVP facilities to compute the minimum MTU over a
           multicast tree and return the result to the senders.

  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.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 1999 13:24:12 -0500

Michael Richardson wrote:
...
> finally push PMTU issues to the front.

Obviously that is the default solution, and it has the property
that it may well cause the tail of packet N to be delivered after
the head of packet N+1 - a performance disaster, but not a
change in the formal default service.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 1999 17:46:13 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Michael Richardson wrote: ...
    >> 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.