Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

Michael Welzl <michawe@ifi.uio.no> Fri, 25 March 2016 08:12 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046D612D610 for <stackevo-discuss@ietfa.amsl.com>; Fri, 25 Mar 2016 01:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTBE8nXysqgX for <stackevo-discuss@ietfa.amsl.com>; Fri, 25 Mar 2016 01:12:57 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3895412DBE2 for <stackevo-discuss@iab.org>; Fri, 25 Mar 2016 01:12:57 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ajMrX-0008FS-Hc; Fri, 25 Mar 2016 09:12:55 +0100
Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1ajMrX-0005h7-3c; Fri, 25 Mar 2016 09:12:55 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <56F427D9.9030208@isi.edu>
Date: Fri, 25 Mar 2016 09:12:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6E55B03-FD33-4EAB-B814-8A4C3E9657EA@ifi.uio.no>
References: <A741874C-0E2C-4905-9FD3-D29B4B94A9C0@ifi.uio.no> <56F3212B.5020408@isi.edu> <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no> <56F32C47.6080707@isi.edu> <271375F3-2B9D-4C61-9C6E-468E6423A1A4@ifi.uio.no> <56F427D9.9030208@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.3112)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 11 sum msgs/h 6 total rcpts 39660 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 5F74E21F29D7DE8C5C90DE5AFB9F9A8CD4B308E6
X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 573 max/h 14 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/bnksSyh3sfNVatwz4sSyV9nnjSw>
Cc: stackevo-discuss@iab.org
Subject: Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2016 08:12:59 -0000

> On 24. mar. 2016, at 18.46, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> On 3/24/2016 1:20 AM, Michael Welzl wrote:
>> 
>>> On 24. mar. 2016, at 00.52, Joe Touch <touch@isi.edu> wrote:
> ...
>>> Having one uniform layer at which multiplexing occurs makes things easy.
>>> Having two means you have to wonder what the other is doing all the time
>>> and whether the two correlate.
>> 
>> Is this a real practical problem related to this draft?
> 
> It is a real practical problem anytime you tunnel.

Even when the method avoids that packets grow in size? I’m surprised but I’m not going to debate this further: you provided a useful pointer (the tunnels draft in INTAREA), I’ll have to take a look and try to understand the problem. Anyway I agree that a solution like the v6 flow labe that Tom Herbert suggested is nicer; I have nothing at all against that and now plan to incorporate it in the next version of the draft, for the v6 case.

As for the congestion control related bits of your email, I made a mistake: I started this off saying “let’s discuss this in ICCRG”, but then I follow up a discussion here on stackevo. This is purely about congestion control, so it really belongs there. My next email in this matter will go to you, cc iccrg.

Cheers,
Michael