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

[Mirja Kühlewind <[e-mail]>]

Hi,

few comments on your use cases
> Am 10.08.2015 um 20:26 schrieb Toerless Eckert <[e-mail]>om>:
> 
> 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).

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

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

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

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