[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] A data point on transit MTU size
Iljitsch,
>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
>Sent: Wednesday, October 01, 2008 7:35 AM
>To: Templin, Fred L
>Cc: Dino Farinacci; tony.li@tony.li; Brian E Carpenter; RRG
>Subject: Re: [RRG] A data point on transit MTU size
>
>On 24 sep 2008, at 19:15, Templin, Fred L wrote:
>
>> I'm not convinced as to how "large" the buffers need to
>> be? AFAICT, the size depends on the number of simultaneous
>> reassemblies in progress
>
>Right. But:
>
>1. This could be a large number. Assume every full size packet is
>fragmented then the number of fragments held at any given time is
>pretty much number of ITRs we talk to / 2
>
>2. It's possible to exhaust limits in this area for DoS purposes
OK, but please check out my other messages regarding
fragmentation/segmentation as an indication that there
are marginal links on the path in need of replacement.
We don't want segmentation/reassembly as a steady-state
condition; we only want it to bridge the gap between
what we have today and a future jumbo-clean Internet.
(Also as a hot-standby in case someone fat fingers a
link MTU configuration or inserts a 90's-era piece of
networking gear.)
>>> Having fixed size per standard makes it much simpler. Don't
>>> have that for IP.
>
>> The most we will ever ask the ETR to reassemble is 2KB. Ever.
>
>Obviously we want the system to be able to handle packets bigger than
>2k if hardware limitations permit, but the only reason for reassembly
>would be the case where the inner packet is 1500 bytes DF=1 so you
>would never have to reassemble more than two fragments, can require
>that those arrive in order, too. Another optimization: require that
>the first fragment is 1024 or 800 bytes or so rather than
>1500, so the
>reassembly buffer only needs to be 1k per session.
So, require that the largest segment be 1KB when we have
to segment? I'm not sure that an ETR would be able to
manage its buffers efficiently in order to take advantage
of that given that it still needs to receive unfragmented
MTU-sized packets, but neither can I guarantee that that
would not be the case. So, I don't see a problem with
what you are suggesting.
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