Subject: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-01.txt

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Jul 2016 17:00:30 -0700

Hello,

I just posted a new version -01 of Transport Over UDP. The major
changes are more elaboration of disassociated location, making session
numbers not be symmetric, more details on session negotiation, peer
address and port learning described, don't use addresses in pseudo
header with TOU, and handling for TCP resets.

I would like to present TOU at the PLUS BOF if possible.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Wed, Jul 6, 2016 at 4:50 PM
Subject: New Version Notification for draft-herbert-transports-over-udp-01.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-transports-over-udp-01.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-transports-over-udp
Revision:       01
Title:          Transport layer protocols over UDP
Document date:  2016-07-06
Group:          Individual Submission
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-01.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/
Htmlized:       https://tools.ietf.org/html/draft-herbert-transports-over-udp-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-herbert-transports-over-udp-01

Abstract:
   This specification defines a mechanism to encapsulate layer 4
   transport protocols over UDP. Such encapsulation facilitates
   deployment of alternate transport protocols or transport protocol
   features on the Internet. DTLS can be employed to encrypt the
   encapsulated transport header in a packet thus minimizing the
   exposure of transport layer information to the network and so
   promoting the end-to-end networking principle. Transport connection
   identification can be disassociated from network location (IP
   addresses) to provide connection persistence for mobility and across
   state eviction in NAT.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Aaron Falk <[email-masked]>
Date: Thu, 7 Jul 2016 18:37:00 -0400

Hi Tom-

One explicit goal of PLUS is to enable controlled communication between endpoints and devices on the network path. As I understand it, TOU is designed to preclude that communication.  As this is a BoF about chartering a working group around PLUS, the TOU draft neither addresses PLUS motivation (e.g., why we need to communicate to middleboxes?) or architecture (e.g., how could we make this communication work in an world with pervasive encryption?).  Since there was some email discussion of your draft on this list, Brian has tried to address the distinction between PLUS and TOU in his slide deck <https://www.ietf.org/proceedings/96/slides/slides-96-plus-1.pdf> (specifically, slide 20) and I encourage you to send any clarification comments to him.

To be clear, this isn’t a reflection on the merits of your proposal, only that it doesn’t address the goals of the BoF: to determine whether the IETF should take on the work described in the PLUS charter.  Indeed, one could consider TOU to be a competing proposal from an applications perspective, one based on a different set of requirements.  I would suggest that it might be a totally reasonable fit with the TSVWG and you might seek agenda time in that working group.  If you are going to discuss TOU in a wg in Berlin, I encourage you to drop a note to the spud list with the specifics.

Best,

—aaron

> On Jul 6, 2016, at 8:00 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Jul 2016 10:36:09 -0500

On Thu, Jul 7, 2016 at 5:37 PM, Aaron Falk <[email-masked]> wrote:
> Hi Tom-
>
> One explicit goal of PLUS is to enable controlled communication between
> endpoints and devices on the network path. As I understand it, TOU is
> designed to preclude that communication.  As this is a BoF about chartering
> a working group around PLUS, the TOU draft neither addresses PLUS motivation
> (e.g., why we need to communicate to middleboxes?) or architecture (e.g.,
> how could we make this communication work in an world with pervasive
> encryption?).  Since there was some email discussion of your draft on this
> list, Brian has tried to address the distinction between PLUS and TOU in his
> slide deck (specifically, slide 20) and I encourage you to send any
> clarification comments to him.
>
Aaron,

I would agree if the goal of PLUS was to provide signaling to network
path for any existing transport protocols (IMO this would have been a
better goal). But, PLUS is explicitly being described for use with
transport protocols over _UDP_. Such transport protocols don't really
even exist yet (TOU and QUIC are being proposed). Without
understanding how transport protocols over UDP will even work I think
it is difficult to design another layer intended to work with them.

Tom