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

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 Apr 2015 15:25:19 -0700

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Apr 2015 15:47:18 -0700

On Fri, Apr 10, 2015 at 3:25 PM, Jana Iyengar <[email-masked]> wrote:
> Toerless, PHB, all:
>
> One response inline, also because it uncovers something that I want to speak
> to:
>
>
>>
> 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.
>
> 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:
> - best practices on various things that commonly affect UDP-based transports
> including known NAT behavior, known practices about UDP blocking, UDP rate
> limiting, etc.
>
> 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, I agree with most of what you are saying except for the part
about looking at "UDP-based transports". I don't think there is such a
thing in the sense that any existing transport protocol can easily be
adapted to run over UDP (UDP, after all, is just an envelope).
SCTP/UDP for instance, would be a great candidate to run over SPUD if
it solves the problems of introducing a supporting a new (non-TCP) IP
protocol on the Internet and is a reliable way to get it through
stateful firewalls. It seems like the direction should be to identify
the minimum information from existing deployed transport protocols
that needs to be exposed to the network-- TCP is obviously a primary
one to look at.

Thanks,
Tom

> - jana
>
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2015 18:54:14 -0700

> want to bolt SCTP on top of UDP, that's fine. SPUD should allow you to do

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

> 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.
   
> developed and deployed; SPUD can do the right thing of tying them at the

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

> are currently running on UDP that don't fit the SPUD world-view will simply

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.

> assuming framing. This is, in general, a difficult but incredibly important

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.

> from the TCP-ese that they are currently tangled in in both RFCs and in

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

> blocking, UDP rate limiting, etc.

Example ?

> 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

-- 
---
Toerless Eckert, [email-masked]