[Spud] SPUD scoping (was Re: SPUD's open/close are unconvincing)

[Jana Iyengar <[e-mail]>]

Toerless, PHB, all:

One response inline, also because it uncovers something that I want to
speak to:

>

> > > What's missing from SCTP ?
> >
> > Quite, do we have the opportunity for a quick fix here? If SCTP has
> > already done all the necessary design work, can we just bolt that on
> > top of UDP in place of IP and declare a quick victory?
>
> You should talk to the SCTP folks or read the specs. I am not
> on top of the details but i think it does a lot of what you ask.
> For me, userland eg: SCTP would be a pre-requisite to make a solution like
> SPUD successful, not an argument to not do SPOD. See my mail where i
> was trying to explain the three layers of the transport stack
> as i would like to see it.
>

I'm quite intimately familiar with SCTP, and what SCTP provides is *not*
germane to whether SPUD should happen or not. The point is to allow for
UDP-based transports to exist, such as Adobe's RTMFP, FaceTime's UDP-based
protocol (whatever that's called), Quake-3's transport protocol, ... if you
want to bolt SCTP on top of UDP, that's fine. SPUD should allow you to do
that.

Architecturally, IMO, the value of SPUD is in bringing some semblance of
shared connection-level behaviors and signaling to UDP-based transports, so
that (i) middleboxes can make life easier for UDP-based transports, and so
that (ii) middleboxes can understand the common design patterns in
UDP-based transports so that they can do middleboxy things better.
UDP-based transports have existed for quite a while, and continue to be
developed and deployed; SPUD can do the right thing of tying them at the
waist.

IMO, it is extremely important to define a narrow waist though, so that
SPUD doesn't ossify the design space atop UDP. UDP is the wild-west right
now; bringing order to this space shouldn't result in a strait-jacketing of
this space. Conversely, if it seems to strait-jacket this design space,
SPUD will likely not take off, simply because the experiments that folks
are currently running on UDP that don't fit the SPUD world-view will simply
not adopt SPUD.

So, in my mind, any effort that seeks to work on enabling UDP-based
transports must find and document shared design patterns in existing
UDP-based transports, and if absolutely necessary, specify bits to be
exposed to the network. There are several things that are behavior and
*not* bits on the wire, but these seem to have been dropped in favor of a
protocol spec. Things such as:
- congestion control for non-TCP transports (we did this for LEDBAT, and
discovered how difficult it was to specify congestion control without
assuming framing. This is, in general, a difficult but incredibly important
exercise.)
- loss recovery ideas (how do you provide reliability?) that are untangled
from the TCP-ese that they are currently tangled in in both RFCs and in
implementations.
- best practices on various things that commonly affect UDP-based
transports including known NAT behavior, known practices about UDP
blocking, UDP rate limiting, etc.

It's quite possible I have a different view of what's useful to be done in
this space. My concern is that conversations here are rushing headlong into
a discussion of a protocol, but if we are talking about an architectural
shift -- where UDP-based transports are increasing in number and scope, and
where we try to engage middleboxes in protocol design --- it seems to me
that our starting questions need to be broader than the specific bits of
the SPUD prototype. And our starting conversations need to include
currently deployed UDP-based transports.

- jana