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

[Toerless Eckert <[e-mail]>]

> On 06 Jul 2015, at 19:20, Tom Herbert <[e-mail]> wrote:
> 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.

Point 2 already expanded by Mirja - not only QoS, but any form
of policy.

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

You just mentioned two key goals. I think there are four:

 1) Common connection layer for transport protocols (your 1)
    for signaling application<->network middleboxes
 2) Common policy signaling layer for transport flows (your 2)
    for signaling application<->network middleboxes
 3) 1) and 2) shareable by existing AND novel transport protocols
    [Existing protocols may duplicate some of 1) and 2) but without
     the ability to signal application<->network well0
 4) Ability to build 1)..3) at the application layer
    Aka: Outside the classical OS to app boundary
    Aka: After OS demultiplexing
    Aka: faster developed, deployed, security-fixed, enhanced,...
    than our existing IETF protocol stack model.
    Aka: must be on top of UDP.

I contend your statement that we will not be able to have reliable
transport protocols run over SPUD. Of course, there is a lot of work to
create successfull proliferation: Browsers, RTCweb,
IoT protocol stacks, Cross-OS Open Source stacks are IMHO four key targets
which are necessary and sufficient to make the SPUD strategy work.

Your mentioning of IP options is quite correct in the face of the
historic OS protocol stack. And we need to change this:

OS:
  routing/forwarding (IPv6)
  OS app-demultiplex (UDP)
Base SDK, bound to OS-app:
  connection signaling
  policy/QoS signaling
    (un)reliable/realtime flow managemenet ("transport")
Higher layer SDK:
  Eg: Browser
Higher layer app
  
Cheers
    Toerless