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-----
- [Int-area] Packing in draft-touch-intarea-tunnels… George Tsirtsis
- Re: [Int-area] Packing in draft-touch-intarea-tun… Joe Touch
- Re: [Int-area] Packing in draft-touch-intarea-tun… George Tsirtsis
- Re: [Int-area] Packing in draft-touch-intarea-tun… Joe Touch