[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.
|>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.
to unsubscribe send a message to firstname.lastname@example.org 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