Re: [Int-area] Packing in draft-touch-intarea-tunnels-00.txt

[George Tsirtsis <[e-mail]>]

Yes Joe, this is exactly what I am looking for, thanks.

I am somewhat concerned with taking something that is done over a
single hop technology (GigE) and applying it blindly to the multi-hop
Internet. e.g., one should think what this would do to packet
fate-sharing and what it would mean for end nodes if/when the tunnel
terminates on them etc.

George

On Mon, Mar 23, 2009 at 1:51 PM, Joe Touch <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, George,
>
> George Tsirtsis wrote:
>> Was just looking at draft-touch-intarea-tunnels-00.txt
>>
>> The section on "Packing (ala GigE bursting)" in this draft is a bit strange.
>> Although this is under a section listing known "issues" with
>> tunnels/fragmentation, it is not clear what the authors think about
>> it.
>> It is almost written as if the authors believe that tunnel packing is
>> a "good thing", is that true or am I mis-interpretatiing?
>
> The point of the doc is to be objective. That means pros, cons, and
> caveats. The doc isn't fully matured, though, and some sections have
> more detail than others. This probably needs development, e.g.:
>
> It you're sending lots of 40-byte packets over a tunnel that can support
> 500-byte packets, then you can do so more efficiently by using packing.
> However, you do run the risk of introducing timing artifacts (bursts)
> into the traffic that goes through the tunnel, and this assumes that
> enough packets arrive at the tunnel ingress to be useful to pack - a
> tunnel ingress shouldn't delay packets just to pack them.
>
> I.e., there are pros (efficiency), cons (timing effects), and caveats
> (no additional queuing delay just to aggregate).
>
> Is that what you were looking for? is that reasonable?
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknH9kQACgkQE5f5cImnZrsgNACfdrnFvtaMbS4sry2sU17iLGzH
> 85oAoIUhN9OzKk6z644KdCmzjLEMuyf9
> =cPCM
> -----END PGP SIGNATURE-----
>