RE: [RRG] A data point on transit MTU size

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Tony,

>Obviously you can optimize, but even a naïve implementation 
>has to have a bound on the number of reassemblies that it can 
>have in progress at any given time.  Again a trivial 
>implementation is to provide a max sized buffer for each such 
>reassembly.

A Linux box is a far cry from a carrier-grade router, but
Linux sets high/low water marks of 256K/192K for its cache
of outstanding IPv4 reassemblies. It also provides a tunable
parameter for how aggressively to purge stale reassemblies.
With SEAL, I believe the tuning parameters for reassembly of
IPv4-fragmented SEAL packets can and should be clamped down
very tightly indeed even for high-end routers (i.e., even to
the point of dropping all IPv4-fragmented SEAL packets) since
SEAL will very quickly tune out all IPv4 fragmentation.

Greater care must be taken with SEAL-layer reassembly, since
SEAL-segmented packets need to be reassembled and forwarded
with high assurance. However, SEAL-layer reassembly in itself
is an indication that there are marginal links in the path
that can be immediately identified and a trouble ticket called
in to their owners. The interdomain routing community peer
pressure alone would serve as ample motivation for upgrading
obsolete network gear to new and relatively inexpensive
equipment that supports jumbo-clean links. The eventual end
state is a jumbo-clean interdomain core, with a transition
timeframe that parallels the rollout of LISP itself.

Fred
fred.l.templin@boeing.com 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg