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

[Brian Trammell <[e-mail]>]

> On 11 Mar 2015, at 14:32, Philipp S. Schmidt <[e-mail]> wrote:
> 
> My first impression about SPUD was more of a session layer than of “just” a middle box signaling layer…
> 
>> On 10.03.2015, at 22:31, Joe Hildebrand (jhildebr) <[e-mail]> wrote:
>> 
>> 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.
> 
> … therefore I would rather think of the Tube ID as some kind of session ID all flows that
> belong to a session share. A little like the key in MP_CAPABLE extension of MPTCP.
> This implies there can be multiple conversations on different 5-tupels sharing a Tube ID.

It seems to me like part of the problem we're having here is that we have (in the SPUD prototype) a single tube ID, which is endpoint and path visible, and we're wanting to do things with it that have fundamentally different scoping rules.

Perhaps we can apply the question that led to the separation of TCP and IP in the first place: does the path need to see it / can the path do something universally useful with it? Put it in SPUD. Is it end-to-end? Stick it above SPUD, encrypt it, and hide the key from the path.

Put that way, session IDs binding flows together seem to me to be an end-to-end thing. But of course different situations might have different requirements.

Cheers,

Brian

>>> 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.
> 
> In case of such a thing, I would rather try to avoid using Tube IDs.
> 
>>> 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.
> 
> The question is: do we care - or do we expect that packets related to this tube should be checked by the application to e.g. allow middle boxes to announce an alternative endpoint by referencing the tube id?
> 
> AVE!
>  Philipp S. Schmidt / phils…
> --
>   {phils}--->---([e-mail])--->---(http://phils.in-panik.de)----,
>      wenn w eine   aube ist dn      man au dran dre en                   |
>           o     Schr        an muss     hc         h   (Kurt Schwitters) |
> :wq!  <---(phone: [phone])---<---(jabber: [e-mail])---'
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud