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

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

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