Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

[Tom Herbert <[e-mail]>]

On Tue, Jul 7, 2015 at 6:43 AM, Brian Trammell <[e-mail]> wrote:
> Hi, Tom,
>
>> On 06 Jul 2015, at 19:20, Tom Herbert <[e-mail]> wrote:
>>
>> On Fri, Jul 3, 2015 at 8:24 AM, Mirja Kühlewind
>> <[e-mail]> wrote:
>>> Hi all,
>>>
>>> we’ve just submitted a new use case document. This document describes in more detail the use cases as already presented/discussed at the BoF.
>>>
>>> Please review and comment. Also partial reviews of e.g. just one use case are more than welcome. Further if you’d like to contribute to this document, please let use know as well.
>>>
>> Hi Mirja, thanks for the draft! Here are my comments.
>>
>> General comments:
>>
>> It seems to me there are two motivations for SPUD:
>>
>> 1) A common protocol layer for UDP flow based protocols to pass
>> through stateful firewalls and NAT.
>> 2) A rich inband flow based QoS signaling initiated by end hosts which
>> can be interpreted by network devices in the path.
>
> Kind of, though it's not *strictly* QoS focused.
>
> There's also (1.5): enable network management functionality which today uses DPI but will no longer function with increasing payload encryption. But the current draft doesn't go into much depth on this point.
>
>> The first motivation seems pretty clear, the inability to pass UDP
>> (really anything besides TCP) through stateful firewalls has impeded
>> deployment of new L4 protocols.
>>
>> The second motivation is less clear. Disregarding previously raised
>> questions around new DoS vectors and whether we can ever trust
>> anything anyone says on the Internet, I would ask if SPUD (UDP) is the
>> right layer for this. The need for this signaling doesn't seem to be
>> specific to UDP transport protocols, but also should applicable to
>> TCP, SCTP, and other protocols. Barring that these protocols
>> transition to running over SPUD (unlikely in the foreseeable future),
>> it seems like such signaling should be implemented in a more common
>> layer, maybe something like IP options.
>
> I tend to think that the signaling vocabulary and encoding(s) should be defined *separately* from the mechanism to bind that encoding into the protocol stack. Taking draft-hildebrand-spud-prototype as an example, one could define a set of CBOR keys that one must understand for a given SPUD application (say, the low latency use case), and then bind those CBOR keys into userspace transports using SPUD, into IPv6 traffic using hop-by-hop and/or destination options (in a world in which those work), etc.
>
> In any case, I think at *minimum* any layer supporting this has to be able to run over UDP, by process of elimination -> you can't always add things to the kernel or get privilege to open a raw socket (i.e. requirement 6.3 in draft-trammell-spud-req).
>
IP is the least common denominator and so use of IP options would be
applicable to all IP protocols, not just a new application based
protocol that currently has zero deployment. This is the appropriate
place for the policy/QoS information information described in the use
cases, and there are already facilities for both hop-by-hop options
and allowing middle boxes to modify options inflight. The ability for
applications and receive and arbitrary list of IP options has long
been supported in kernels (IP_OPTIONS and IP_RECVOPTS socket options),
so I really don't see any argument that kernel can't provide necessary
support.

Tom