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

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

>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.com] 
>Sent: Wednesday, September 24, 2008 12:56 AM
>To: tony.li@tony.li
>Cc: 'Brian E Carpenter'; Templin, Fred L; 'RRG'
>Subject: Re: [RRG] A data point on transit MTU size
>
>> Patently nonsense.  Packet reassembly in hardware is very much
>> straightforward if one is willing to burn large buffers to do so.   
>> Imagine
>
>The willing part is the impossible part.

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 plus the degree to which the
network mis-orders packets plus the degree to which stale
reassemblies are garbage-collected. This, plus SEAL puts
a firm cap of 2KB as the largest size an ETR will ever
have to reassemble.

Think of ETR reassembly in a LISP/SEAL world as an
indication of discomfort ("pain" would be too strong
a word). The way to migrate toward greater degrees of
comfort is to incrementally identify and weed out the
marginal links. 

>> taking an implemention in C and simply converting it to Verilog.   
>> Not at all
>> out of the question.
>
>It certainly is.
>
>> In fact, a subset of this problem has been solved for a very long 
>> time.
>> Remember ATM?  Remember a SAR chip?  That's reassembly of fixed size 
>> packet fragments.
>
>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.

Fred
fred.l.templin@boeing.com

>
>Dino
>

--
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