The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <852569B5.00722D9D.00@ussmtp01.ftl.telematics.com>, Keith.Schuettpel
z@go.ecitele.com writes:
> 
> 
> 
> Eric Gray wrote:
> 
> > Consider this.  You are about to discard a packet
> > because it is to large.  Who cares if you do this on the
> > slow path?
> 
> I see at least 2 issues...
> 
> 1) If you need to fragment the packet rather than discard it
> Doing this in the slow path can result in packet re-ordering w.r.t.
> subsequent smaller packets processed in the fast path.
> Is this acceptable?


Generate ICMP if DF is set or silently discard if DF is clear might be
the best thing to do.  Attempting to fragment the DF-clear traffic and
dropping if the rate was too high would be fine as long as it couldn't
result in any sort of denial of service or instability due to
processor loading.

PMTU (rfc1191) will still work if packets without DF are discarded.
TCP implementations that don't use PMTU will break if they use the
local interface MTU and packets without DF are discarded.


> 2) If you need to send an ICMP message back to the source.
> How fast must the slow path be in order to handle all of the
> concurrent PMTUD's being performed by the many TCP flows
> passing through a core link? I.e. What percentage of the packets will
> be performing PMTUD and have the DF bit set, requiring the generation
> of an ICMP message?


When PMTU is used, the TCP flows only very rarely send a larger packet
to probe the MTU size.

An abnormal case would be a reroute that results in a smaller MTU.
This is where the LSR must be able to survive a transient period where
it is called upon to generate ICMP and fragment at a very high rate.


RSVP-TE has it right.  If tunnel reroutes using make-before-break, the
MTU changes at the ingress and any ICMP or fragmenting happens there.


Curtis