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

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



On 20 dec 2007, at 19:52, Templin, Fred L wrote:

Just to have disclosure for the current understanding
of this out on the list, the full proposal is given
below.

I think this is a good way to make the fragmentation issue as painless as possible IF we choose to accept it, with one important and a minor caveat.

So at some point we should try to get consensus about whether we want to allow fragmentation or not. We may as well do that now...

The important caveat is: when do you send back a too big message to the original source? This is clearly what needs to happen if the original source performs path MTU discovery properly, which is fortunately still what most (right?) hosts do. The problem is that you can't simply send too bigs for all packets that are too big, because that way you would be performing a denial-of-service attack on hosts that don't honor these messages. And, more imporantly, you'd probably be wasting local CPU cycles unless you have silicon for ICMP generation. Would simply rate limiting too bigs be a workable approach? I guess it would be if you don't drop the packet but fragment it, although that behavior wouldn't be expected by the source host (but hey, stranger things have happened in the name of the unreliable datagram). If you drop the packet, you'd probably do that for several in a row so TCP would be taking a nap for a while when that happens.

it sends 1500- original packets into the tunnel as
either 1-fragment or 2-fragment packets of no more
than (750+ENCAPS) bytes each.

This can probably be further optimized to be aligned with memory buffers.

We could even generalize this to: =< 1024 or > 2048 are never fragmented, 1024 - 2047 byte packets are split into a packet with the first 1024 bytes of the original packet and a second packet with the remaining bytes.

(Making the packets roughly equal size minimizes the chances of subsequent fragmentation and making the first no smaller than the second avoids the first one from arriving first when the two fragments travel over parallel paths, both issues that I don't think are all that important here.)

In both cases, the assumption is that original
sources that send 1501+ packets are also doing something
like RFC4821. This should appear in a BCP document.

If we use a few bits in the encapsulation header to ask the decapsulator to send ACKs for selected packets (see my message to Dino earlier this week, and probably one later today) then the encapsulator could do its own RFC 4821 based on the data packets. I think that would be extremely useful.


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