Subject: [Spud] Details about PLUS BoF

From: Natasha Rooney <[email-masked]>
Date: Mon, 20 Jun 2016 16:58:36 +0000

Hi all,

***** Upcoming BoF *****
I am sure you all know that there will be a PLUS BoF at IETF96! According to the current (preliminary) agenda the current slot is Thursday Morning Session 1[1].

***** Chairs Selected *****
Aaron Falk and I (Natasha Rooney) are very happy to be your chairs for the BoF! We’ll be working over the next few weeks with the BoF proponents and presenters to make sure the BoF asks the right questions and everyone involved is prepared to make the right decisions.

***** Mailing List and BoF Name *****
Some of you may be confused with the naming of the BoF and this mailing list. Between now and IETF96 please continue to use the SPUD mailing list [2] for discussions about SPUD and the PLUS BoF. If the PLUS BoF agrees to form a working group we will create a PLUS mailing list then, but this will only be *after* IETF96. So (again just for clarity!), keep using the SPUD mailing list for now.

If you have any questions for the chairs or AD please feel free to post them to the SPUD list.

Thanks!

Natasha

[1] https://datatracker.ietf.org/meeting/96/agenda.html
[2] [email-masked]<mailto:[email-masked]>

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 12:30:56 -0700

On Mon, Jun 20, 2016 at 9:58 AM, Natasha Rooney <[email-masked]> wrote:
> Hi all,
>
> ***** Upcoming BoF *****
> I am sure you all know that there will be a PLUS BoF at IETF96! According to
> the current (preliminary) agenda the current slot is Thursday Morning
> Session 1[1].
>
> Aaron Falk and I (Natasha Rooney) are very happy to be your chairs for the
> BoF! We’ll be working over the next few weeks with the BoF proponents and
> presenters to make sure the BoF asks the right questions and everyone
> involved is prepared to make the right decisions.
>
> Some of you may be confused with the naming of the BoF and this mailing
> list. Between now and IETF96 please continue to use the SPUD mailing list
> [2] for discussions about SPUD and the PLUS BoF. If the PLUS BoF agrees to
> form a working group we will create a PLUS mailing list then, but this will
> only be *after* IETF96. So (again just for clarity!), keep using the SPUD
> mailing list for now.
>
Hi,

I've posted draft-herbert-transports-over-udp-00.txt on the spud list
that describes methods to run transport protocols (like TCP) over UDP.
This includes a "shim" UDP layer protocol. Is this the scope of the
PLUS BOF for discussion?

Thanks,
Tom

> [2] [email-masked]
> Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |
> [email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype:
> [email-masked]
>
>
> This email and its attachments are intended for the above named only and may
> be confidential. If they have come to you in error you must take no action
> based on them, nor must you copy or show them to anyone; please reply to
> this email or call +44 207 356 0600 and highlight the error.
>
>
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Jun 2016 13:12:46 -0700

Hi Tom,
On Mon, Jun 27, 2016 at 12:30 PM, Tom Herbert <[email-masked]> wrote:

> > If you have any questions for the chairs or AD please feel free to post
> them
> > to the SPUD list.
> >
> Hi,
>
I've read draft-herbert-transports-over-udp, and my take was that it was an
argument that the need for path layer was not proved.  Two bits in
particular stand out for this:

   This solution espouses a model that only the minimal
   necessary information about the packet is made visible to the
   network. This exposed information is sufficient to route the packet
   through the network and to demultiplex and decrypt the packet at the
   receiving end host. In particular, the encapsulated protocol and
   related connection state may be rendered invisible to the network.
   Additionally, this solution allows encapsulation of IPv6 extension
   headers, particularly destination options, which can then also be
   hidden from inspection in the network.

and

   TOU implements a subset of the the SPUD architecture but expressly does
   not require or include provisions to leak end-to-end information
for consumption
   in the network. The encapsulation protocol used in TOU (GUE) is
   extensible to optionally allow information exposure if this proves to
   be warranted.

When a transport protocol's state machine is expressed in clear text, it
can be interpreted by path elements and it thus creates a sort of implicit
path layer.  PLUS is arguing that the use of clear text should end, and
that the path layer should be made explicit with the control over what is
being said at that layer handed firmly to the end systems.  They can choose
to say nothing, of course, and that would result in something very similar
to TOU, at least as I understand it.

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.

Do I have that approximately correct?  If so, can you indicate what kind of
evidence you are looking for and how we could gather it in a TOU-based
encapsulation?  Would it be deploy and see where it doesn't work?

regards,

Ted

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 14:28:27 -0700

On Mon, Jun 27, 2016 at 1:12 PM, Ted Hardie <[email-masked]> wrote:
>    not require or include provisions to leak end-to-end information for
> consumption
> When a transport protocol's state machine is expressed in clear text, it can
> be interpreted by path elements and it thus creates a sort of implicit path
> layer.  PLUS is arguing that the use of clear text should end, and that the
> path layer should be made explicit with the control over what is being said
> at that layer handed firmly to the end systems.  They can choose to say
> nothing, of course, and that would result in something very similar to TOU,
> at least as I understand it.
>
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.

> encapsulation?  Would it be deploy and see where it doesn't work?
Deployability of TOU should be directly correlated to deployability of
UDP. I think there's already good evidence in
https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf and
some of the QUIC numbers. What is not reflected in those are some
important use cases where the network provides valuable optimizations
based specifically on TCP (maybe optimizations for 2G, 3G like in
RFC3481). It might be interesting to see if ancillary data could be
added to a packet get such optimizations for non-TCP or UDP-based
transports, but again it doesn't seem like we can wait for such things
to be defined in a standard and fully deployed before we start using
encrypted UDP-based transports.

Tom

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Jun 2016 10:33:24 -0700

> tangible benefit to our traffic or it "fixes" whatever networks are
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.

To put this another way, the existence of a common PLUS substrate is not
meant to imply that it will become a requirement for all UDP flows.

regards,

Ted

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jun 2016 11:26:24 -0700

On Wed, Jun 29, 2016 at 10:33 AM, Ted Hardie <[email-masked]> wrote:
> 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. In fact, I think
we are going to see more cases of flows taking alternate paths within
their lifetime. 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. 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?).

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. 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).

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

Thanks,
Tom