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

[Ken Calvert <[e-mail]>]

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

Seems like the 40-byte limit in v4 would make it difficult to do some things you might want to do, especially as hash sizes keep growing.

I like the viewpoint someone (Brian, I think) suggested earlier:  the network layer header effectively includes the  UDP header.  So SPUD could be viewed as a way of carrying network layer options (in addition to transport info).

Ken Calvert