Subject: new Path MTU requirement in new RSVP-TE draft

From: Markus Jork <[email-masked]>
Date: Wed, 12 Jul 2000 11:14:11 -0400

There is now a new section 2.6 in
draft-ietf-mpls-rsvp-lsp-tunnel-06.

It basically says that an ingress LSR has to keep track
of the Path MTU for each LSP (an information that is
gathered by RSVP) and fragment all packets it sends into
that LSP accordingly.

Where does this requirement come from now and why
is it a "MUST" requirement? I think this puts too much burden
on the ingress LSR. So this really should be a "MAY".
A midpoint LSR has to be able to do the fragmentation
if required.

Markus

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Jul 2000 15:09:18 -0400

Markus Jork wrote:
> 
> There is now a new section 2.6 in draft-ietf-mpls-rsvp-lsp-tunnel-06.
> 
> It basically says that an ingress LSR has to keep track of the Path
> MTU for each LSP (an information that is gathered by RSVP) and
> fragment all packets it sends into that LSP accordingly.
> 
> Where does this requirement come from now and why is it a "MUST"
> requirement? I think this puts too much burden on the ingress LSR. So
> this really should be a "MAY".  A midpoint LSR has to be able to do
> the fragmentation if required.

There are several reasons.  A big reason is that transit routers might
not be capable of fragmenting labeled traffic.

Another is that it is difficult (if not impossible) to guarantee end-to-
end bandwidth and/or delay reservations if transit routers are allowed
to fragment packets.

The reason is simple - fragmentation increases the amount of bandwidth
used - by adding more headers to the stream.

If the amount of traffic entering the LSP is at (or close to) the
reserved capacity, fragmentation will cause this traffic to violate the
reservation after the node where the fragmentation occurred.  This may
cause the packet to be dropped by a transit node in the tunnel, which
would be bad.

I think it is generally assumed that traffic entering a tunnel,
compliant with that tunnel's reservation, will emerge from the other
end.  (Not counting failures or best-effort tunnels, of course.)

If all fragmentation is done by the ingress node, then it can make sure
that all traffic entering the tunnel is compliant to the reservation.

Additionally, doing all the fragmentation in one place means that less
fragments will be generated, and that most of the fragments will be of
maximal size.

For instance, imagine a case where an 8192-byte packet hits an MTU-1500
link, then an MTU-1009 link, then an MTU-576 link.  If each router does
its own fragmentation, you end up with 17 fragments; if this packet is
fragmented directly to 576, however, you end up with 15 fragments.  You
save the bandwidth of two IP headers, MPLS headers and layer-2 headers. 
If you get a lot of oversized packets, this can be significant.  (It can
be even more significant if there is a wider variety of MTUs in use in
the network.)

-- David

---

From: Markus Jork <[email-masked]>
Date: Wed, 12 Jul 2000 16:00:40 -0400

> not be capable of fragmenting labeled traffic.

Are there any transit routers that do not support this?

I know that in general, "fragmentation is considered harmful". And
I'm not saying it's a bad idea to do the fragmentation at the sender only.
But the best place to do the fragmentation is at the original data
source, the end system sending the packets (this is what IPv6 enforces).
That seems like a better place than in some backbone router
which acts as an LSP ingress and now has to keep track of the path mtu for
all of its LSPs.

Also, a big part of my concern is the fact that this is quite a major
change in the draft pretty late in the game.
Is there anything like this in CR-LDP?

Markus

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Jul 2000 16:09:54 -0400

Markus Jork wrote:
>>
>> There are several reasons.  A big reason is that transit routers
>> might not be capable of fragmenting labeled traffic.
> 

I don't know.

I do know that an ATM switch can't fragment packets.  But it would never
have to either - since it is just forwarding cells anyway.

> source, the end system sending the packets (this is what IPv6

Of course, but a router must deal with the possibility that some hosts
won't perform MTU discovery.

Also, a transit MPLS router might not be able to generate ICMP messages
when dropping oversize packets - which would break MTU disovery.  (The
ingress node can do this as well as fragment them, of course.)

> That seems like a better place than in some backbone router which acts
> as an LSP ingress and now has to keep track of the path mtu for all of
> its LSPs.

If an oversized packet is admitted, it is going to be fragmented or
dropped by someone.  Better that the core transit routers (which will be
using the fastest links) not have to.

Note also that (at least with RSVP), the edge routers already know the
MTU for every LSP.  MTU is calculated hop-by-hop during Path processing
(using either the CoS-type TSpec or an Adspec object).  The result is
then sent back in the FlowSpec object that is part of the Resv message.

-- David

---

From: Lou Berger <[email-masked]>
Date: Wed, 12 Jul 2000 17:02:51 -0400

David,
         I think you're pretty close on this whole topic.  The one 
additional piece of information is that a transit LSR may not know if 
there's an IP header within the LSP and so may not know how to handle a 
"too big" packet.  In this case, MTU discovery would break.  The current 
text is carefully wording to not break MTU discovery.  For nodes that can't 
or don't track MTU per LSP, there's an out (taken from the encap draft) of 
having a "Maximum Initially Labeled IP Datagram Size"

The authors of the encap draft promised to put out an updated rev with some 
related discussion.  I haven't seen it and don't know if it's going to be 
out this week.

Lou