Subject: Re: [tsvwg] The List (of application-layer desired features)

From: Nico Williams <[email-masked]>
Date: Fri, 30 Aug 2013 16:50:15 -0000

- HTTP needs an XID so as to make it less dependent on octet stream
transports.  HTTP chunks, so there's no need for sub-channels, as long as
an XID can be used to dissociate reply order from request order.

- SCTP and similar should be implemented in user-space -- the OS/NIC should
know nothing more than how to classify packets for dispatch purposes.  UDP
obviously facilitates this and has the benefit that middle boxes deal with
it.

- Multi-homing and name resolution should be abstracted from the app, even
if they are handled within the app (in a library).

- The tricky things are a) security (SYN forgery type attacks), and b)
congestion control.  We know how to do (a) with low latency sometimes
(e.g., see TCP Fast Open).  (b) is trickier; read with care (has the IAB
said anything about this?).

- User/service authentication and session crypto are orthogonal to the
above: TLS and similar can be adapted to unreliable, unordered datagram
delivery, and they have been (DTLS).  This is not to say that we have
nothing to do in this space, just that it's mostly orthogonal to the
transport issues/wish-list.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 05 Sep 2013 03:14:21 -0000

Yes, deployable means: doesn't require middle-box updates
(NAAAAAAAAATs) and doesn't require OS vendors / kernel developers /
distros to develop, package, and deliver an implementation.  That
pretty much means: plain TCP and plain UDP.  Not IPsec (sure, IPsec
can run over UDP, but apps can't all run their own IKEs), not SCTP
(unless it's over UDP), not TCP-AO or anything of the sort.

Things like SCTP over UDP will do.  Lighter-weight protocols over UDP
too.  Just make sure to handle congestion.

DJB's MinimaLT looks pretty good.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Oct 2013 10:28:43 -0700

On 9/4/2013 8:14 PM, Nico Williams wrote:
> Things like SCTP over UDP will do.

By your set of requirements, *anything* over UDP would work fine. 
Including IPsec, TCP-AO, and anything else you can dream up.

Thank you for moving the stack up one level, adding 20 bytes of header, 
and constraining the number of connections between two hosts (due to the 
limit of port numbers).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Oct 2013 10:31:47 -0700

> Thank you for moving the stack up one level, adding 20 bytes of header,

(I intended to make that 8, 28, or 48, depending on whether you embed 
another layer of IPv4 or IPv6 header too).

---

From: Michael Welzl <[email-masked]>
Date: Fri, 11 Oct 2013 10:14:25 +0200

On 30. aug. 2013, at 18:50, Nico Williams wrote:

> - HTTP needs an XID so as to make it less dependent on octet stream transports.  HTTP chunks, so there's no need for sub-channels, as long as an XID can be used to dissociate reply order from request order.
> 
> - SCTP and similar should be implemented in user-space -- the OS/NIC should know nothing more than how to classify packets for dispatch purposes.  UDP obviously facilitates this and has the benefit that middle boxes deal with it.
> 
> 
AFAIK a pretty well working version of SCTP in user-space exists, and this is also what's used in Firefox for the rtcweb data channel.

> - Multi-homing and name resolution should be abstracted from the app, even if they are handled within the app (in a library).
> 
+1

> - The tricky things are a) security (SYN forgery type attacks), and b) congestion control.  We know how to do (a) with low latency sometimes (e.g., see TCP Fast Open).  (b) is trickier; read with care (has the IAB said anything about this?).
> 
> 
RFC 3714 is a congestion control related RFC from the IAB. There's also more RFCs with general recommendations, and a RFC 5783 gives an overview of all of them (up to the date of its publication).

> - User/service authentication and session crypto are orthogonal to the above: TLS and similar can be adapted to unreliable, unordered datagram delivery, and they have been (DTLS).  This is not to say that we have nothing to do in this space, just that it's mostly orthogonal to the transport issues/wish-list.
> 
> Nico
> --
> 

Cheers,
Michael

---

From: Nico Williams <[email-masked]>
Date: Fri, 11 Oct 2013 11:24:53 -0500

On Thu, Oct 10, 2013 at 12:28 PM, Joe Touch <[email-masked]> wrote:
> By your set of requirements, *anything* over UDP would work fine. Including
> IPsec, TCP-AO, and anything else you can dream up.

Well, not TCP-AO.   But, yes.

> Thank you for moving the stack up one level, adding 20 bytes of header, and
> constraining the number of connections between two hosts (due to the limit
> of port numbers).

As if it were my fault.  It's not.  Or as if blame for this can be
properly allocated.

And anyways, no, we could run lots of [end-to-end] things over UDP in
such a way that the port numbers from the UDP header need not be
repeated at higher layers.  But being able to use a single port for
lots of communications streams is useful to deal with the second
problem you note.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Oct 2013 17:25:10 -0700

> Well, not TCP-AO.   But, yes.

TCP-AO would work fine, presuming it's TCP over UDP, or TCP over IP over 
UDP.

> As if it were my fault.  It's not.  Or as if blame for this can be

"you" is also plural, and by encouraging this sort of approach, you are 
a member of the group.

> repeated at higher layers.

You can reinvent the entire IP stack over a single UDP port. We've been 
around this block before with HTTP.

> But being able to use a single port for

Useful in what sense? More fragile when dealing with changes in routing 
that alter which NATs are traversed? Providing the ability to reinvent 
the entire IP stack above UDP in a way that won't (can't) interact 
correctly with the native IP stack?

Joe