IETF Logo Mail Archive

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

Tom Herbert <tom@herbertland.com> Wed, 23 March 2016 23:51 UTC

Return-Path: <tom@herbertland.com>
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 8F0E412D626 for <stackevo-discuss@ietfa.amsl.com>; Wed, 23 Mar 2016 16:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 tEQOJEPLhBcP for <stackevo-discuss@ietfa.amsl.com>; Wed, 23 Mar 2016 16:51:29 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 942BA12D0FB for <stackevo-discuss@iab.org>; Wed, 23 Mar 2016 16:51:29 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id 124so69241076iov.3 for <stackevo-discuss@iab.org>; Wed, 23 Mar 2016 16:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=RHeRV18kKwiRHQVk4vU+YNb24lz0pU6N8iCxWRmZ9Cc=; b=eIsfr11OgUBmqmgYxtqWutkamOiz4fRZgp6SoSYhVTlOEuc5ZarsCm2P1Kc6RIukeo EmQ+kOq0nWtdPuMMkQsRNEEGL1RaRrC1sPCoUfCHMXHH2MbRppvm49X4Dq0vsJbIvW66 WuJhFDRR4zelFSqCqPwgJdfVtgRyNwp2EnKawnia4F1nkB4KE6OXJBGmyRfeseyYvl0W OYZbAXcWOm5QELKTxxF5v+/X258NgA6Cm+AqiITHV/xGK3OVWH3GtE6Vh4IEAaGFWEiH CcX9JZdk2QT3uT0aqej2aPIGB3JZE3Etv5ggB+48Y3b3qzG5wiZNR7WQ3LiZ3p6ozqRB 7Fug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=RHeRV18kKwiRHQVk4vU+YNb24lz0pU6N8iCxWRmZ9Cc=; b=PhlKx4YNb2mPrFKX4isklnobpNoLHFtzzlta/ietBwaWraUcJmNEj9DGjBNJS0ZVJy lHZGmVV/8A2L7iEE4UPugVSwSJBUW5PscdBHl9+gtSnA3a942Q18dcOWpcjr8oy4Yuim wV6W4PbU0Dns3Pv6FoO/KAOPWKAGd4biul9dswjPvvChpTopBBgd+H+ZeFlaUuIixUDf +kyIzSZ0M5gE6MAxeoIKarbBCbdjCLj/ib/1e8ag/0yXBRavXIfQi68YJpr8ZYCT/XSh UOVHQqIOnZ38EptkcM6R/dRjO3x+PKNgYQ2xG+S3eWB8pgR42vl7qxBTfhnC+GED2Bgp tQJg==
X-Gm-Message-State: AD7BkJJhnTuoewhd4THcROo6pkrWZHKvWRvV73rlXLTDwSZGqHecDs9hmLaLE7FOLY5TDgkuDdVp6bL9Uda1og==
MIME-Version: 1.0
X-Received: by 10.107.10.103 with SMTP id u100mr6451076ioi.50.1458777088831; Wed, 23 Mar 2016 16:51:28 -0700 (PDT)
Received: by 10.107.130.198 with HTTP; Wed, 23 Mar 2016 16:51:28 -0700 (PDT)
In-Reply-To: <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no>
References: <A741874C-0E2C-4905-9FD3-D29B4B94A9C0@ifi.uio.no> <56F3212B.5020408@isi.edu> <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no>
Date: Wed, 23 Mar 2016 16:51:28 -0700
Message-ID: <CALx6S35n8bD6UwGT823S8dhmzncm3=B_VYrKbm0sgzv35-weRQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/ZlZrlrIi9AL8yA4P3_cbefOHPpU>
Cc: stackevo-discuss@iab.org, Joe Touch <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:51:31 -0000

On Wed, Mar 23, 2016 at 4:43 PM, Michael Welzl <michawe@ifi.uio.no> 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.
>
>
>> 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 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.
>
You should be able to accomplish the "same path" behavior by setting
IPv6 flow label same value for different connections between same IP
pair. This avoids all the unpleasantness that accompanies
encapsulation.

Tom

> Cheers,
> Michael
>
> _______________________________________________
> Stackevo-discuss mailing list
> Stackevo-discuss@iab.org
> https://www.iab.org/mailman/listinfo/stackevo-discuss

v2.23.0 | Report a Bug | By Email