Re: [Spud] Details about PLUS BoF

Brian Trammell <ietf@trammell.ch> Sun, 03 July 2016 13:59 UTC

Return-Path: <ietf@trammell.ch>
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 F057912B007 for <spud@ietfa.amsl.com>; Sun, 3 Jul 2016 06:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lKBUp2nRrEXI for <spud@ietfa.amsl.com>; Sun, 3 Jul 2016 06:59:28 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2812B006 for <spud@ietf.org>; Sun, 3 Jul 2016 06:59:27 -0700 (PDT)
Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 94FDC1A19FC; Sun, 3 Jul 2016 15:58:55 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D18813E5-480D-4EA3-A112-9788E6DF0744"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <CALx6S34=AmMFgFxZ5FtesgO5xApjnTSmQ3o1Ykah-ZodaEmmxg@mail.gmail.com>
Date: Sun, 03 Jul 2016 15:58:54 +0200
Message-Id: <657B751A-8AF1-42F5-8451-D04688544490@trammell.ch>
References: <D374C0BA-E03F-45B7-B8B8-9F8BFBBE5802@gsma.com> <CALx6S35Bh-8SWRvcKhrOPmPpHadcE3Orb0qJb6qFrNq_i0fWBg@mail.gmail.com> <CA+9kkMA_8ec9=R4sy=2x1WPU2QJpWogLOaJU+s8jTw-oaKPY=A@mail.gmail.com> <CALx6S37hZgmvxJTRkgyDWLO2Ct3WMJ7T6o--_Ntks8CjXZ8zFQ@mail.gmail.com> <CA+9kkMCc6T54UYVS+e3-dXbC7E75b=qXPEZFPEk8y39fU3wxQQ@mail.gmail.com> <CALx6S34=AmMFgFxZ5FtesgO5xApjnTSmQ3o1Ykah-ZodaEmmxg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/6kzm4s_ETX3GGPrIk63iD49kwNs>
Cc: Ted Hardie <ted.ietf@gmail.com>, Natasha Rooney <nrooney@gsma.com>, spud <spud@ietf.org>
Subject: Re: [Spud] Details about PLUS 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: Sun, 03 Jul 2016 13:59:31 -0000

> On 29 Jun 2016, at 20:26, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Wed, Jun 29, 2016 at 10:33 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> On Mon, Jun 27, 2016 at 2:28 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> 
>>> On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>> 
>>>> 
>>>> You appear to be saying that the eliminated implicit path layer simply
>>>> should not be replaced in UDP encapsulations unless evidence comes
>>>> through
>>>> to define what information should be exposed.
>>>> 
>>> Right. Consider that we want to deploy encrypted UDP-based transports
>>> in the near term and that no middlebox supports anything resembling
>>> PLUS. In the simplest model, either a network path forwards UDP
>>> packets without impediment or it doesn't. If it doesn't we will
>>> fallback to TCP and probably alert the user of that at some point. If
>>> PLUS does come on-line then it's worth using only if it provides some
>>> tangible benefit to our traffic or it "fixes" whatever networks are
>>> still blocking UDP.
>>> 
>> 
>> So, having the path forward UDP packets without impediment should be a
>> consistent aim.  The idea behind an explicit path layer is to move from
>> "without impediment" to "with optimization".  If an endpoint is is willing
>> to inform the path of session start and stop for a UDP-based flow, for
>> example, it may get the longer dwell times in NAT bindings that are
>> currently available to flows that reveal that in an implicit path layer.
>> That advantage might translate to avoiding heartbeat traffic, which is quite
>> useful.
>> 
> Ted,
> 
> IMO the idea that the network should be tracking session state like
> that is a red herring because it presumes that the "path" of a flow is
> well defined and has some invariant hops. IP is a packet switched
> network architecture, not circuit switched. There has never been
> either a protocol nor architectural requirement that packets of any
> flow always go through the same intermediate device.

Agreed. This is why, e.g., TCP anycast is such a terrible idea, and is completely undeployable.

Someone should probably point this out to the people deploying it: see e.g. [1], [2]. Cicalese et al had a nice measurement study on this in CoNext last year, too [3].

> In fact, I think
> we are going to see more cases of flows taking alternate paths within
> their lifetime.

I hope we do. Restoring the ability to safely treat IP as a packet-switched architecture is one of the goals of this work (see the SPUD use cases draft, section 6 [4]). As of today, since common wisdom holds that TCP performance *sucks* if you reorder packets, quite a lot of effort goes into reducing reordering within a flow, and it turns out an excellent way to do that is to make sure all the packets in a flow hit all the same queues in the absence of rerouting. How can a transport signal that reordering is tolerable today?

> Consider that any smart phone is now typically
> multi-homed to both a mobile network and a WIFI network. It's pretty
> obvious that we'd like to seamlessly transition from using one network
> to the other without breaking established connections.

This world has existed for a couple of decades now: SCTP (where it deploys) and MPTCP do this already by building a session over multiple transport connections.

> In that world
> I'm not even sure what sort of PLUS state signaling would be
> meaningful (e.g. when transitioning do we need to send a PLUS 'FIN'
> into the old network, and a PLUS 'SYN'  to the new one?).

Simple: map the transport layer signaling for the individual transport connections to the state signaling on PLUS.

> In any case, state signaling to the network seems at best to be a
> hint. Any intermediate devices that tracks tries to track stack must
> realize they could be completely wrong and need to take this fact into
> account.

Absolutely. We spend a fair amount of time making this clear in the requirements document (see requirements 5.7-5.9 [5], though it turns out that the mechanism for 5.7 and 5.8 are probably identical).

> And if the network can't provide any assurances to the host
> given the signaled state, for instance a guarantee that NAT bindings
> are maintained for the duration of the connection, then the only
> recourse for the host has is to fallback to assuming network doesn't
> track state (e.g. still needs to send keepalives to maintain NAT).

This is also covered in the documents (see esp. use case 3). The goal is to reduce the aggregate nonproductive traffic in the network once PLUS-aware middleboxes are deployed, not to make guarantees for any particular flow or path.

> As for the NAT binding issue, I believe that IPv6 is supposed to
> obsolete the need for NAT in the first place.

Heh. Someone should point this out to all the people working on the menagerie of ways to make IPv4-only services accessible on IPv6-only access networks.

Cheers,

Brian

[1] http://blog.catchpoint.com/2015/09/24/tcp-over-ip-anycast/
[2] https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
[3] http://conferences.sigcomm.org/co-next/2015/img/papers/conext15-final100.pdf
[4] https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-01#section-6
[5] https://tools.ietf.org/html/draft-trammell-spud-req-04#section-5.7 et seq.