<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Proposal: Compression of large packets: fragmentation
From: Josef Drexler <jdrexler,AT,josefsbox,DOT,cjb,DOT,net>
Date: Mon, 3 Dec 2001 19:54:33 +0100
In-reply-to: <Pine.LNX.4.21.0112030056280.27557-100000@raid.kaico.com>

On Mon, 3 Dec 2001 ewheeler,AT,kaico,DOT,com wrote:

> If we send a packet > than some router's MTU, it will get fragmented.  If
> we drop a fragment, the entirepacket needs retransmitted.
> Questions:
> 1. Does cipe already handle this?

It doesn't need to.  For tunneled tcp/ip connections it will be handled by
the tcp/ip layer, and for tunneled udp or other datagram services, the
application can never assume guaranteed delivery anyway.

> 2. Will adding compression to skb->data before crypto complicate this
> matter?

As long as compression is done on a per-packet basis, it won't matter.  We
just have to make sure that each packets can be decompressed individually
without knowledge of any prior packets.

This could be done by using zlib's compress() function, or to use a
dictionary that we reset for each packet -- this might give better
compression but needs coordination between both cipe peers.

> 3.  Is there a way to find the max MTU for a specific route?  If I have a
> site in redmond, and portland, I would like to set the MTU to the maximum
> non-fragmenting size; so the router whose MTU is the smallest.

This should not matter.

> 4.  I have w2k/9x systems using WINS to connect over a CIPE connected
> VPN.  Would setting the workstations on either end of the VPN to
> 1442 reduce fragmentation and decrease latency due to fragmented
> packets?  Would there be any side effects to this?

Except perhaps slightly lower performance, no.

   Josef Drexler                 |    http://publish.uwo.ca/~jdrexler/
 Please help Conserve Gravity    | Email address is *valid*.
 Don't hike up a mountain.       | Don't remove the "nospam" part.

<< | Thread Index | >> ]    [ << | Date Index | >> ]