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

[Toerless Eckert <[e-mail]>]

On Fri, Apr 10, 2015 at 03:25:19PM -0700, Jana Iyengar wrote:
> 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.

Right. I was primarily pounding on how SPUD can help proliferate work
on reliable transport layer over UDP. But its equally valuable to provide
a lightweight "connection layer" for datagram transport protocols like you
mention them. So that three layer transport that i dres (UDP+SPUD+Proto)
should defnitely be inclusive of datagram and reliable "Proto".

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

Right, I'd maybe just call it "connection oriented datagram service protocol",
but that doesn't include those aspects of it that interact with middleboxes.
   
> 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.

Not quite sure i get that picture. Do i have to loose weight to use SPUD ? ;-))

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

Well... lets see. 

As a cynical aside: i am not sure your premise is correct. HTML (pre 2.0)
was a real protocol for a lot of things put into it, but yet it was done because
it did help so much to get through FW. And lo and behold, no 20 years later
we have HTML 2.0. SO maybe we just need to make SPUD successfull, however much
it sucks, and the rest will resolve itself in time ;-)

What SPUD should provide is primarily the minimum necessary and sufficient
to get better through future middleboxes. I can think different type of middleboxes
may have different degree of requirements, but ultimately, you shouldn't need to
have more in SPUD than what those middleboxes want you do do - or what the
SPUD application wants them to do.

I think extensibility would be good to bake into the design.

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

Well... I think SPUD should include elements for common "QoE" interactions
with middleboxes. Packet priority, signaling of bandwidth etc. pp. Those
would be leveraged by congestion control end-to-end. I don't think that
we could define an actual congestion control mechanism into SPUD because
work like LEDBAT, RMCAT and all the other stuff going on shows that we do
want and need to support a variety of different congestion control mechanisms.

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

Can you give an example ? My pet topic of course are indications of
drop-priority at packet level, also because this would nicely match abilities
of key transport media like wireless (higher reliabiliy == more bandwidth
required for packet because of higher probability for L2 retransmit).

> - best practices on various things that commonly affect UDP-based
> transports including known NAT behavior, known practices about UDP
> blocking, UDP rate limiting, etc.

Example ?

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

Imagine you had a nice concept requirement but no ida how you would code it
into the actual protocol bits (and how middleboxes should interact with it).
In a waterfall process we'd write it down and a year later we discover we
can't figure out how to do it, only that we likely wasted a lot of time figuring
out its interations in before. So the use of a SPUD prototype protocol that
we can bitch about how to modify is IMHO primarily a tool to keep the discussion
close to the metal and focussed on deliverying useable code more than long
documents.

Cheers
    Toerless

> - jana

-- 
---
Toerless Eckert, [e-mail]