Subject: RE: IP Fragmentation before entering LSP

From: [email-masked]
Date: Tue, 5 Jun 2001 14:44:42 +0530

hi nagendra!
     The concern regarding the fragmentation is raised in case the the QoS
classification of a packet is based on the L4+ information i.e. like what type
of application does the packet belong to (SAP, HTTP etc. for example). In this
case the fragmented packets will not have enough information to be classified
and hence the discussion above.

regards
sumit

Nagendra Singh Tomar <[email-masked]> on 06/05/2001 02:53:58 PM

Please respond to [email-masked]

To:   Ron Bonica <[email-masked]>
cc:   David Charlap <[email-masked]>, [email-masked] (bcc: Sumit
      Chauhan/HSS)

Subject:  RE: IP Fragmentation before entering LSP

Hi!
     Can anyone tell me what is this concern about fragment
re-ordering ?? IP fragmentation/reassembly is immune to fragment
re-ordering, then why is this concern in the last few mails in this
thread. I can understand the other concerns shown in this thread.

regards
tomar

On Mon, 4 Jun 2001, Ron Bonica wrote:

> Dave,
>
> As you have observed, options 1 and 3 may not be compatible with line rate
> forwarding in the network core. Option 2 may cause fragment re-ordering.
>
> A fourth option is to prevent all fragments from traveling on an LSP. If
> possible, forward all fragments using standard IP forwarding mechanisms. If
> this is not possible, discard the datagram.
>
>                                      Ron
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of David
> > Charlap
> > Sent: Monday, June 04, 2001 12:44 PM
> > To: [email-masked]
> > Subject: Re: IP Fragmentation before entering LSP
> >
> >
> > Vishal Mishra wrote:
> > >
> > >     How are fragmented IP Packets identified by the Ingress LER
> > > if the basis of classification involves part of the IP Payload,
> > > such as the Transport Layer address (say UDP Port) ?
> > >
> > >     Does this mean only the first fragment of all such IP Packets
> > > travel through the Traffic Engineered LSP, and the rest of the IP
> > > fragments (being unclassified) follow the best effort (Non-TEed)
> > > Path ?
> > >
> > >     This would lead to a whole lot of problems (including out of
> > > order packets).
> >
> > If the ingress LER is going to classify on L4+ information, then that
> > information must obviously be present.  There are only three possible
> > choices I can see here:
> >
> > 1: Have the ingress LER reassemble the fragments before injecting
> >    into the LSP (possibly re-fragmenting them after reassembly).
> >    The upside is that it eliminates this problem altogether.  The
> >    downside is that it may be impossible to do this at line-rate,
> >    and the router will have to deal the the possibility that some of
> >    the fragments may never arrive (perhaps they got routed through
> >    some other router, or perhaps they were lost.)
> >
> > 2: Have the ingress LER forward the first fragment (the one with the
> >    L4 header) according to its policy, and ignore the L4 information
> >    for other packets.  The upside is that you don't have to worry
> >    about late/missing fragments.  The downside is that the first
> >    fragment may take a different route through the network from the
> >    other fragments, leading to out of order delivery.
> >
> > 3: Have the ingress LER use stateful packet inspection.  When the
> >    first fragment arrives, it should record enough information to be
> >    able to recognize the remaining fragments and send them into the
> >    same LSP.  The upside is that it solves the problem and you don't
> >    need to buffer the entire packet.  The downside is that the first
> >    fragment may not arrive first, and that you need to deal with the
> >    possibility that one or more fragments may never arrive.
> >
> > The only way to avoid the problem altogether is to restrict your packet
> > classification to what is available in the IP header.  But this may not
> > be acceptible to all customers.
> >
> > -- David
>

--

------------------------------------------------------------------------------
 Nagendra Singh Tomar

 Residence:
 369 KHB Colony
 5th Block Koramangala
 Bangalore 95
 INDIA
 Phone : 5524839
 email : [email-masked]

"Sometimes quantity becomes quality"
                            --Gary Kasparov,
 When he played against Deep Blue. He said this after looking at a
 computer which found a forced mate in 249 in an endgame, after calculating
 all the possible moves with only 5 pieces left on the board.
------------------------------------------------------------------------------

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Tue, 5 Jun 2001 16:39:13 +0530 (IST)

Hi Sumit!
	Thanx for the reply, but my question was not "Why is fragmentation
a concern " but Why is fragment re-ordering a concern" ..

cheers
tomar

-- 

 Residence:
 369 KHB Colony
 5th Block Koramangala
 Bangalore 95
 INDIA
 Phone : 5524839

---

From: Eric Gray <[email-masked]>
Date: Tue, 05 Jun 2001 10:42:17 -0400

Nagendra,

    Vishal's original question had to do with a general concern that already
fragmented UDP packets might arrive at a point where a TE LSP originates.
If the basis for ingress to the TE LSP is a specific L4 attribute, it is possible
that the first IP fragment will qualify for ingress and the rest will not.  While
out of order delivery is a concern in this situation, perhaps a more important
concern is that the 'service' associated with the TE LSP was meant to apply
to the entire UDP packet.  Since all but the first fragment do not receive this
'service' (whatever it is), the entire packet is at least as bad off as if no part
of it received the 'service'.

    The issue with re-ordering IP fragments is that many stack implementations
do this somewhat sub-optimally.  Thus, if fragments are re-ordered, this could
lead to further degradation of the 'service' intended for this packet.

    An example of a 'service' degradation might be the case where a certain class
of UDP packets are intended to be filtered (possibly to prevent certain types of
denial of service attack).  In this case, filtering the first fragment could result
in
a greater 'denial of service' impact that if the filtering service did not exist.

    I think Dave Charlap and Ron Bonica were going in the right direction with
their
suggestions.  It seems to me that the LSR at the ingress needs to be more aware of
its limitations.  If it is not able to ensure that all subsequent IP fragments will
go
on the same LSP, it should not admit the first one.  Either it uses Dave's options
1 or 3, it forwards using IP or it drops the packet (as Ron suggested).  Note that
this is also consistent with Jay's initial suggestion to employ the same policy to
all IP fragments.

--
Eric Gray