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

[Toerless Eckert <[e-mail]>]

On Tue, Aug 11, 2015 at 11:36:13AM +0200, Mirja Kühlewind wrote:
> > 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.

I disagree.

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

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.

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

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.

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

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

> Mirja
> 
> 

-- 
---
Toerless Eckert, [e-mail]