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

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2015 10:52:49 -0700

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 <[email-masked]> 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​

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 11:26:48 -0700

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
> view, can you please explain????

Correct guess.

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

I don't follow.

> 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

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.

> > ???If by "all" you mean "all of it passing it", then sure; if you mean "all"
> information about the??? tube that is consumed by a path element on the

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 11:43:51 -0700

Sigh... resending. [email-masked] mailing list owner hansn't bumped up the Cc limit...

On Mon, Aug 10, 2015 at 06:13:28PM +0000, Christian Huitema wrote:
> I don't know what Toerless really means, but I am a bit concerned by the use of a "unique identifier" here. Specifically, I am concerned with the privacy implications of using unique identifiers. If the same identifier is used with multiple 5 tuples, then it can be used to tie together these tuples. There are cases when it doesn't matter too much, e.g. when just the client port changed, presumably after a NAT remapping. But if the client IP address changes, the unique identifier provides a neat way to track successive locations of a mobile device.

Sure, thats the purpose. As i said too, nobody forces higher layer protocols to
reuse the same Tube-ID. They would do it, when it gives any of the benefits
that i've listed in my last reply to Ted.

> I understand that using a unique identifier simplifies the device greatly. For example, a load balancer can use the unique identifier to ensure that packets are always routed to the "right" context. But we can do better than that. In fact, we should, because without a good alternative protocol designers will just pick the simple design, without worrying too much about privacy. The alternative is to design a privacy preserving way to bind two contexts together. 

forgot the load balancing example , thanks.

> That shouldn't be too hard. For example, the client could send a "tying" parameter encrypted with the server public key, tying the new context to a previous one. But we probably want to start this kind of design sooner rather than later, especially if we care about privacy.

Well, the problem with the security is always how to establish a trust
relationship between middlebox and endpoints. As i mentioned, there
should be some good resistance to reinvent the wheel, but i don't think
threre is a good wheel yet.
> -- Christian Huitema

-- 
---
Toerless Eckert, [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2015 18:13:28 +0000

On Monday, August 10, 2015 10:53 AM, Ted Hardie wrote:

> ...
> I've split off a small chunk here to focus on the multipath/mobility question.
>
>> My preference for Tube-ID is to identify a single bidirectional multipath or
​> 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?​

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 11:35:09 -0700

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Aug 2015 11:36:13 +0200

Hi,

few comments on your use cases
> Am 10.08.2015 um 20:26 schrieb Toerless Eckert <[email-masked]>:
> 

As this is end to end it should be in the overlaying transport and encrypted such that the network can’t see it.

>   and there is a common layer helping to idenfiy sub-flows of a connection.

Diagnostics seem to be the one argument why leaking on any information seems to be useful. I don’t think diagnostics should be an argument to give up privacy. Further as long as I don’t see a very good example why especially it is needed to know that two different flows belong to the same app/user for a very concrete case, that argument is to general for me.

> c) ability to do less per-sub-flow signaling by using state data from another

We are talking about potentially having a spud header in each packet to support state handling.
I don’t see a reason to re-use state information from a different flow (not even sure how this would exactly look like).

> d) Ability to do resource tracking/assignment across a multi-path/mobile flow.
So tracking is the case we want to avoid! All the network needs to know is: Please thread these packets together with preferentially that service. Especially if you try to use two different paths for you flows (multi path), there is no need to connect packet of different flows together.

Mirja

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 03:27:11 -0700

On Tue, Aug 11, 2015 at 11:36:13AM +0200, Mirja Kühlewind wrote:
> As this is end to end it should be in the overlaying transport and encrypted such that the network can???t see it.

I disagree.

> Diagnostics seem to be the one argument why leaking on any information seems to be useful. I don???t think diagnostics should be an argument to give up privacy. Further as long as I don???t see a very good example why especially it is needed to know that two different flows belong to the same app/user for a very concrete case, that argument is to general for me.

Every enterprise customer trying to manage a network and figuring out
why apps don't work or why traffic is not what it should be needs diagnostics
for multipath traffic to figure this out. Heck, just comparing the bitrates
of two sub-flows to diagnose the WAN congerstion domains.

Btw: I would bother wondering about privacy for stuff that sits on top
of an API that provides an actual transport connection. Without creating
diagnostics for network/transprt layer itself you're creating an unmanageable
mess. I understand how folks are also trying to exploit privacy at
lower layers, like privacy addresses and the like, and i don't want to
stop any of that, but i don't want those folks to stop the option of
having diagnostics for network/transport.

> I don???t see a reason to re-use state information from a different flow (not even sure how this would exactly look like).

The SPUD header should be small, so i would constrain it to only
per-packet attributes like packet priority, ECN and the like. The per-flow
attributes could only be in specific signaling packets like START/STOP
related ones. If for example an app goes through the long list of
ICE matrix local X remote address for connections, we might be ale to
ue the Tube-ID to speed up stuff. Haven't quite tried to build out the
workflow yet.

> So tracking is the case we want to avoid! All the network needs to know is: Please thread these packets together with preferentially that service. Especially if you try to use two different paths f…

Disagreement. You use different addresses local/remote and two
of these flows go through a single congestion point, then the network
thats trying to provide fairness might want to give you bandwidth for just
one actual connection instead of two flows - if you are so nice to the
network of letting it know about this fact. Again: its the choice of
a collaborative application.

Cheers
    Toerless