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

Joe Touch <touch@ISI.EDU> Mon, 23 March 2009 21:17 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5453A6C86 for <int-area@core3.amsl.com>; Mon, 23 Mar 2009 14:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCnoMl76rEu4 for <int-area@core3.amsl.com>; Mon, 23 Mar 2009 14:17:33 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AEE833A6C3D for <int-area@ietf.org>; Mon, 23 Mar 2009 14:17:33 -0700 (PDT)
Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2NLGYxF023892; Mon, 23 Mar 2009 14:16:36 -0700 (PDT)
Message-ID: <49C7FC31.2010609@isi.edu>
Date: Mon, 23 Mar 2009 14:16:33 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: George Tsirtsis <tsirtsis@googlemail.com>
References: <d3886a520903231337y6a5fea02sc42b0f25a07f2ded@mail.gmail.com> <49C7F645.5000903@isi.edu> <d3886a520903231411u70acc66bi89c042b1e7786029@mail.gmail.com>
In-Reply-To: <d3886a520903231411u70acc66bi89c042b1e7786029@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: int-area@ietf.org
Subject: Re: [Int-area] Packing in draft-touch-intarea-tunnels-00.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 21:17:34 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



George Tsirtsis wrote:
> 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.

Agreed. It also impacts packet fate sharing over lossy tunnels.

Thanks - I'll put that in the update.

Joe

> George
> 
> On Mon, Mar 23, 2009 at 1:51 PM, Joe Touch <touch@isi.edu> wrote:
> 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

iEYEARECAAYFAknH/DEACgkQE5f5cImnZrsIowCbBm7mQqRggZoUN8LUun+0DCg1
arUAnj2c6dUEzkRw/+7BOcZyG46l955L
=epMx
-----END PGP SIGNATURE-----