Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

Joe Touch <touch@isi.edu> Mon, 23 May 2016 16:01 UTC

Return-Path: <touch@isi.edu>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACD212D998 for <spud@ietfa.amsl.com>; Mon, 23 May 2016 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 78r5SPnrSxoQ for <spud@ietfa.amsl.com>; Mon, 23 May 2016 09:01:47 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 F000712D995 for <spud@ietf.org>; Mon, 23 May 2016 09:01:46 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NG0so9017716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:00:56 -0700 (PDT)
To: Brian Trammell <ietf@trammell.ch>, Tom Herbert <tom@herbertland.com>
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch> <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch> <655C07320163294895BBADA28372AF5D4885CF80@FR712WXCHMBA15.zeu.alcatel-lucent.com> <CALx6S37br_VkDrggO1gAh2LzZtm=BTNTEecRU3sRQmUrnR+r7g@mail.gmail.com> <BC2E47D5-1B2B-4848-BBA0-0E5254F125FF@trammell.ch> <CALx6S35syvAFGbgOYvNf-n23T3-QrrUn=9ymyoEvoDvYruoANQ@mail.gmail.com> <A240EFEC-E22E-4960-BA98-D400FFA7647B@trammell.ch>
From: Joe Touch <touch@isi.edu>
Message-ID: <57432936.4080503@isi.edu>
Date: Mon, 23 May 2016 09:00:54 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <A240EFEC-E22E-4960-BA98-D400FFA7647B@trammell.ch>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u4NG0so9017716
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/dRSKZI_PyNAVNo76tgyijV5FIhY>
Cc: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 16:01:53 -0000


On 5/23/2016 6:44 AM, Brian Trammell wrote:
>> On 20 May 2016, at 18:03, Tom Herbert <tom@herbertland.com> wrote:
>> ...
>> DSCP is properly network-layer. If you believe in a "path layer" (which I'm pretty sure I do), you can argue that ECN is the first path layer protocol.
>>
>> I'm not sure what "path layer" is. Yes every packet takes some path,
>> but the Internet is packet-switched not circuit-switched, so not all
>> packets for a flow are required to always take the same path.
>> Maintaining flow state in intermediate nodes is only best effort. In
>> the presence of multi-homing and mobility intermediate devices that
>> track flow state will inevitably have it wrong. Anyone who has ever
>> tried to build a front-end L4 load balancer understands this problem
>> all too well :-)
> Your L4 load balancer is a path layer device. 

The only notion the Internet has of a path is a flow label.

Transport IDs identify services and connections within an endpoint, and
are not universally available or meaningful except at the endpoints.

All attempts by intermediate devices to rely on those identifiers makes
assumptions about visibility and correlation to desired shared-path
behavior that are baseless.

This is the key reason why MP-TCP is very badly misnamed. It is
multi-endpoint, not multipath, and always has been.

Joe