Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

["Joe Hildebrand (jhildebr)" <[e-mail]>]

On 3/10/15, 3:15 PM, "Brian Trammell" <[e-mail]> wrote:

>What I can see being useful here is a facility built in to the "core" spud vocabulary that says "this tube is related to some other tube, here's the ID", for a small set of values of "related". This is more a signal to the remote endpoint than the path, though, so it's not clear it needs to be exposed in SPUD. 

I think you're right that the tube relationships don't need to be made explicit to path elements.  Stitching together multiple tubes into a session-like thing seems like a job for the new layer inside SPUD.  In this case, whenever you needed a new 5tuple, you'd crank up a new tube.  Similar to mptcp, but without tying the flows together.

>One tube ID linkage that would need to be exposed to the path is "prefer to drop packets in this tube before packets in tube ID x" or "prefer to forward packets in tube ID x before packets in this tube", which gives you a nice simple vocabulary for expressing almost everything you need to for differential QoS from a given source without allowing global marking with all its attendant mark inflation problems.

That's a different kind of relationship than I was considering.  I think that would Dan Wing and Pal Martinsen the tools they need for media QoS.  

>Of course, since everything along the path and everything cooperating with everything along the path knows the tube id, any tube linkage features probably have implications for spoofing we'll need to be careful about.

There would have to be some sort of proof that the flows are from the "same" endpoint; maybe the open packets would include something signed by the same private key, for instance.


-- 
Joe Hildebrand