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

[Toerless Eckert <[e-mail]>]

On Mon, Aug 10, 2015 at 10:52:49AM -0700, Ted Hardie wrote:
> ???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????

Correct guess.

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

a) Simplification of multi-path/mobility end-to-end operations.  The Tube-ID
   becomes the identifier for the multi-path flow. Its how additional 
   5-tuples indicate which flow they belong to. (thats pure end-to-end).
b) Diagnostics. Operator, management tools, statistics gatherings,
   troubleshooting. As in: may also help the user if something goes wrong
   and there is a common layer helping to idenfiy sub-flows of a connection.
c) ability to do less per-sub-flow signaling by using state data from another
   sub-flow.
d) Ability to do resource tracking/assignment across a multi-path/mobile flow.

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

I don't follow.

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

Look at it the other way: application will try to game the network by
using more flows to get more bandwidth. So networks may want to limit
number of flows per subscriber or the like (ip-prefix, location, however
you want to bucketie flows) to counter that abuse.

How do we allow for applications to still do multi-path/mobility without
running into the trap of being throttled because they use more flows ?
By giving a network visibile identification of a flow that includes
mobility/multipath. Thats that the Tube-ID could ideally be IMHO.

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

For the end-to-end operations, use of SPUD signaling elements creates
commonality which IMHO is a good thing. And of course it does enable
network elements to easie interact with it.

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

I was not expressing an opinion of whether this should or should not be
supported by SPUD, i was just trying to classify an option, so no reason
yet to agree or disagree ;-)

What i meant to characterize is simple that currently middleboxes only
work for TCP if they see packets for both directions of a connection. So
a) means features in SPUD that would allow middleboxes to only see one
direction of a bidirectional flow and still see all SPUD signaling elements,
eg: because each signaling element is reflected back in the other direction
(or at least the ones necessary to have a middlebox understand the current
state of the connection).

> > ???I don't think I understand what value you think there is here.

Today the locations for middleboxes are engineered so that they see
bidirectional traffic. With this features, middleboxes could more easily
be deployed in parts of the topology subject to hot-potato routing.

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

But there is no unidirectional traffic signaling to set up a "connection"
even for a unidirectional flow. And even if you want to set up a unidirectional
flow, its always one and the same app that owns the sockets for both directions,
so it looks a lot more logical to me to have just a single bidirectional Tube-ID
and just indicate the characteristics of both directions via different
attributes. 

Another way to look at it: Show me a single transport protocol today that
can set up for the same 5 tuple two separate & independent unidirectional flows.
I am not aware of any. Why introduce it with SPUD ?

Cheers
    Toerless