[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