Re: [PANRG] About Keith and Michael's proposal on sidecar protocols in PANRG today

[Michael Welzl <[e-mail]>]

> On Mar 25, 2022, at 6:51 PM, Holland, Jake <[e-mail]> wrote:
> 
> On 03-25, 7:38 AM, "Michael Welzl" <[e-mail]> wrote:
>> this sounds like we’re on the same page. I think being able to saturate capacities should be our primary goal, and maybe we should *really* care about long-term fairness in Congestion Avoidance once we have real-life sightings of this strange beast again (a CA phase that lasts more than a handful of round-trips, maybe even competing for capacity with anything).
>> 
>> But yes… we can surely add complexity to be theoretically sound  :-)
> 
> Of course, passing information about MP to an on-path proxy
> introduces a new kind of information leakage that might pose a
> privacy concern (especially if detailed rate or cwnd information
> about alternate paths is needed), since MP is sometimes cited as
> a possible mechanism to defeat on-path traffic analysis.

I suspect that, if something like this SC would exist, the world would divide into two types of traffic (because folks may prefer this kind of simplicity):  1) I don’t care about privacy => use the SC.  2) I do care about privacy => don’t use it at all. In this view, this extra information leakage doesn’t matter very much. But perhaps I’m simplifying too much.


> So there may be a tradeoff here between CC fairness and privacy
> considerations.  Hopefully the discussions will either find an
> uncontroversial solution that makes everyone happy or give us
> some important new understanding about concerns in path-aware
> networking (or both).

I don’t see that tradeoff. It’s not “be fair __or__ leak information” - it’s: “if you use that thing, you lose privacy, AND (unless we fix this, which may well be doable) you might not be fair”.
“you might not be fair” doesn’t matter very much either, since it’s typically not the users who care…    I think we’re discussing a corner case now, in terms of relevance.  15 other problems to work out before I’d worry about this detail  :-)

Cheers,
Michael