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

[Tom Herbert <[e-mail]>]

On Fri, Apr 10, 2015 at 3:25 PM, Jana Iyengar <[e-mail]> wrote:
> 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, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>