[Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)

[Ted Hardie <[e-mail]>]

Howdy,

I've split off a small chunk here to focus on the multipath/mobility
question.

On Mon, Aug 10, 2015 at 12:28 AM, Toerless Eckert <[e-mail]> wrote:

>
> My preference for Tube-ID is to identify a single bidirectional multipath
> or
> mobile transport connection consisting of one or more 5-tuple flows between
> two endpoints.
>
>
​First, I'm guessing that you want a single tube-id for multiple flows
because you want to tell the network that they are part of a single,
multipath whole.  If I have guessed that wrong and you have a different
view, can you please explain?​



> I can't see how we could have network elements understand multipath/mobile
> connections without such a common identification. Sure, this means SPUD
> would
> need to define a common multipath/mobility layer, but thats a good thng.
>
>
​I think we need to understand what the network will do with this
information.  At the moment, if SPUD can tell the network something about
the treatment desired (e.g. drop preferred over buffering) and tell it that
about a specific flow, I think we have made progress in being more
explicit.  But telling the network something like "this flow and that flow
are related in that some higher layer would see them as part of the same
stream" doesn't actually directly help any particular network element know
what to do.  It may infer what to do based on the idea of multipath, but it
seems generally more effective to be direct.  If you can be direct, to put
this another way, there is no need to leak to the network element anything
about the shape of the flow.

The same seems to me true for the mobility case. The layer at which to do
session replacement seems to me the encrypted transport above SPUD; that
provides better confidentiality.  Now, if the API allows that higher layer
to know what SPUD identifiers were assigned, then it may exercise the
session replacement by saying "This new tube replaces the former tube
identified by tube-id:XXX", but that has to be said in the
cryptographically protected session and backed by  something else (shared
cryptographic credentials with the previous tube, most likely) to be
accepted. But the use of a tube-id there is just an optimization for the
higher layer protocol not generating its own identifiers, and it is
completely opaque to SPUD itself.


> And this can be done incrementally. SPUD can start first defining just
> single 5-tuple mechanisms, as long as w don't block the way to make it
> support
> multipath/mobility.
>
> And transport protocols like MP-TCP that want to continue work unchanged
> can always choose different Tube-IDs for their different 5-tuples.  Likely
> at future loss of best interaction with the network though.
>
> Unidirectional, you have to specify what you really want:
>
> a) SPUD signaling is built such that a network device only seeing a single
> direction of the flow (asymmetric routing as common in the internet)
> still gets all SPUD signaling information.
>
> ​If by "all" you mean "all of it passing it", then sure; if you mean "all"
as in anything related to the tube, then I don't agree.  If I relate
information about the​ tube that is consumed by a path element on the
forward path, then I don't see why it would be echoed to the reverse path
at all.


> For example, each endpoint
> could just reflect the other sides last SPUD message. I think this is
> useful but difficult, and current midpoints don't expect to be able to
> work under these conditions anyhow. SO it might be a useful value add
> to make midpoints support SPUD..
>
> ​I don't think I understand what value you think there is here.


> b) SPUD signaling is bidirectional but allows to identify separate
> information for both direction.
>
> I definitely think this is useful, but i don't see why both directions
> would need separate Tube-IDs.
>
> c) SPUD signaling is unidirectional only for a unidirectional only traff
> flow.
>
> This makes things quite difficult, especially anything security. I
> would reserve thinking about purely unidirectional signaling for multicast
> if you ever want to support that - because those flows are intrinsically
> unidirectional. In Unicast i wouldn't bother.
>
> ​I find myself on the complete opposite end of this--I think app-to-path
signalling is inherently unidirectional for unicast traffic.  You may have
very different path requests for forward and reverse paths and you may have
unidirectional unicast flows.

regards,

Ted​