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

Joe Touch <touch@isi.edu> Wed, 23 March 2016 23:53 UTC

Return-Path: <touch@isi.edu>
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 DC26012D9A1 for <stackevo-discuss@ietfa.amsl.com>; Wed, 23 Mar 2016 16:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 AqxD6Wr9M9zD for <stackevo-discuss@ietfa.amsl.com>; Wed, 23 Mar 2016 16:53:05 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E746A12D96B for <stackevo-discuss@iab.org>; Wed, 23 Mar 2016 16:53:04 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2NNqdQu007216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Mar 2016 16:52:40 -0700 (PDT)
To: Michael Welzl <michawe@ifi.uio.no>
References: <A741874C-0E2C-4905-9FD3-D29B4B94A9C0@ifi.uio.no> <56F3212B.5020408@isi.edu> <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no>
From: Joe Touch <touch@isi.edu>
Message-ID: <56F32C47.6080707@isi.edu>
Date: Wed, 23 Mar 2016 16:52:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/N5DmmPHS4GXTQypKejNwzCmsMZw>
Cc: stackevo-discuss@iab.org, touch@isi.edu
Subject: Re: [Stackevo-discuss] Fwd: 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: Wed, 23 Mar 2016 23:53:07 -0000


On 3/23/2016 4:43 PM, Michael Welzl wrote:
> 
>> On 24. mar. 2016, at 00.05, Joe Touch <touch@isi.edu> wrote:
>>
>>
>>
>> On 3/23/2016 4:42 AM, Michael Welzl wrote:
>>> I'm sending this here as well because it relates to the idea of "running the Internet over UDP" (which, I noticed, is presentation that Brian will give in MAPRG: https://datatracker.ietf.org/meeting/95/agenda/maprg/ ).
>>> This draft explains how we think it should be done with TCP; we believe that it can have quite significant positive side-effects, mainly because of the opportunity to combine the congestion controls of multiple connections.
>>
>> Ick.
>>
>> We went through this before multiple times. One notable was the impact
>> of chunking and muxing in HTTP, effectively reinventing IP inside.
>>
>> "A person with one watch always knows what time it is. A person with two
>> is never sure.”
> 
> I don’t think I follow this, sorry.

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.

>> I can't imagine what combined congestion control of TCP would mean
>> inside the network - we had a hard enough time defining it for either
>> TCB sharing or the Congestion Manager just at the endpoints.
> 
> I don’t get this either; it sounds like a misunderstanding?
> 
> So the encapsulation here is just meant to force packets to take the 
> same path - else the Congestion Manager may be doing something
> pretty wrong.

The CM is supposed to react to E2E congestion, which is the sum of all
effects of the different paths that packets can take.

The idea that packets need to take a single path is an ATM concept, not
IP. I think the Internet would be a lot better off if we just admit that
it's *based* on the idea that packets can use different paths, and that
this is a good thing.

> The sender-side behavior then couples connections; this could be 
> done via the Congestion Manager, or in a way similar to TCB sharing,
> or with our algorithm (which is somewhat similar to TCB sharing).
> That’s why we call it “example algorithm” - think of this as “UDP
> encapsulation forces TCP connections on the same path so we can use
> the CM”. That’s really all it is.

"all it is" is a complete reimplementation of everything in IP inside
UDP -- because everything that IP provides will ultimately be need by
this layer, as well as a way to map this to the corresponding IP mechanism.

I think it would be useful to take a deeper look at the implications
before jumping into this water.

Joe