[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 
Hi Fred, Dino,

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


Well, that sounds like a personal problem.  ;-)


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


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.

If folks want to do a more sophisticated implementation, then it wouldn't be
too hard to use sparse matrix techniques and/or cell techniques to segment
incoming fragments into cells and then reassemble the fixed sized cells.
This reduces the problem to one that's previously been solved.


Tony


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