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

[Brian Trammell <[e-mail]>]

> On 08 Jul 2015, at 17:54, Tom Herbert <[e-mail]> wrote:
> 
> 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,

As to appropriateness, yes, I agree completely.

> not just a new application based
> protocol that currently has zero deployment.

...which I will note is precisely as much deployment as any IP options based approach would have on day zero; the question of how to get the data into the packet is IMO separate from the adoption of the data model of the exposed data itself.

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

Indeed. This presumes that new IP options are more realistically widely deployable in the Internet than a new protocol over UDP. I would need to see some data to back that up (indeed, this would fit nicely in a measurement study we're running right now so we may well end up generating that data. :) )

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

...which at least makes these accessible from platforms which let the apps muck about with socket options.

Thanks, cheers,

Brian

> 
> Tom
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud