Subject: [PANRG] About Michael's proposal on sidecar protocols in PANRG today

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Mar 2022 13:43:42 +0100

Dear PANRG,

I liked Michael's proposal, and I suggest that we spend some time thinking
about interaction with multiplath, now that all REAL transport protocols
support multipath ... 😀

Best,

Spencer

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 24 Mar 2022 13:40:49 +0000

Hi Panrg and Spencer,

I might have liked Michael’s proposal too, I’m still not quite sure yet.  To me the tricky-sounding parts go beyond multipath (though multipath can certainly be a stopper or complication for some potential solutions).

Stuff I like:

  *   I think it makes great sense in general to find a way to give the endpoints some kind of hint and ongoing guidance saying “your end-to-end congestion controller is probably going to be making deeply stupid performance choices unless you listen to me”, which I think(?) is roughly the core purpose of a PEP.
  *   I also think the hash-based acking of packets (I think at the UDP payload layer?) is a natural mechanism to do that with, once you’ve got the endpoint<->PEP communication channels you’d need.

Stuff I’m unsure of:

  *   The part about how to get the endpoint-PEP communication channels you’d need sounds tricky
  *   I’m not so sure about ignoring multiple on-path PEPs.  If you want to handle both satellite and microwave, it’d be nice not to declare that out of scope too early.  (I won’t insist on including it in the end if there’s an otherwise good proposal that can’t do that, but I would prefer answers to “how to do the endpoint-PEP communication” that don’t make this impossible, if there are multiple answers that are approximately equally good.)

I can think of a few ways to do those endpoint-PEP channels, but if you want to talk to the client side as a PEP you’re going to very likely have NAT issues too, and I think(?) you might need to talk to the client side to do a good job as a pep.  At very least if you want retransmits after downstream loss to be a part of this story, but probably also if you want to be able to drain the pep’s queue in a reasonable way.

So maybe you have to successfully talk to the server first (which a PEP could maybe do on a well-known port on the sender’s IP, offering a client cert to identify itself so servers can do some vetting?) and the server could relay the PEP’s server name to the client so it could open a connection and get the channel it needs as well?  I’m not sure.  I don’t offhand see another way for the PEP to reach the client thru a NAT unless it injects something in the target stream in a way that passes the NAT, which seems... probably trickier.

Anyway, very interesting question.  I do hope there’s a good answer here, and thanks Michael and Keith for raising it, you’ve definitely got me thinking.

-Jake

PS: I think some PEPs operate as a 2-ended tunnel over (for instance) a satellite link, rather than a single on-path node.  I think some possible approaches here won’t care, but others might.

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu,2022-03-24 at 5:44 AM
To: "[email-masked]" <[email-masked]>
Subject: [PANRG] About Michael's proposal on sidecar protocols in PANRG today

Dear PANRG,

I liked Michael's proposal, and I suggest that we spend some time thinking about interaction with multiplath, now that all REAL transport protocols support multipath ... 😀

Best,

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Mar 2022 15:05:59 +0100

Hi !

Many thanks for the friendly words - actually, many thanks to everyone today for that!
Some comments below:

> On Mar 24, 2022, at 2:40 PM, Holland, Jake <jholland=[email-masked]> wrote:
> 
> Hi Panrg and Spencer,
>  
> I might have liked Michael’s proposal too,

Keith & Michael’s !   Importantly, Keith deserves the credit for splitting this off into a separate protocol, which is the really main deal here IMO.

> I’m still not quite sure yet.  To me the tricky-sounding parts go beyond multipath (though multipath can certainly be a stopper or complication for some potential solutions).
>  
> Stuff I like:
> I think it makes great sense in general to find a way to give the endpoints some kind of hint and ongoing guidance saying “your end-to-end congestion controller is probably going to be making deeply stupid performance choices unless you listen to me”, which I think(?) is roughly the core purpose of a PEP.
> I also think the hash-based acking of packets (I think at the UDP payload layer?) is a natural mechanism to do that with, once you’ve got the endpoint<->PEP communication channels you’d need.
>  
> Stuff I’m unsure of:
> The part about how to get the endpoint-PEP communication channels you’d need sounds tricky
> I’m not so sure about ignoring multiple on-path PEPs.  If you want to handle both satellite and microwave, it’d be nice not to declare that out of scope too early.  (I won’t insist on including it in the end if there’s an otherwise good proposal that can’t do that, but I would prefer answers to “how to do the endpoint-PEP communication” that don’t make this impossible, if there are multiple answers that are approximately equally good.)

So we all agree that there are some tricky things to work out - and that’s even with only a single SC proxy. Sure, supporting multiple would be nice, but … you don’t even need to consider multipath to see problems with this.
First, SC proxy 2 ACKs to SC proxy 1 about a specific flow X. Then, flow X doesn’t even traverse SC proxy 1 anymore, only SC proxy 2. How would SC proxy 2 know?

That thought alone made me feel like looking at the root of a tree… out of which endless branches can grow.

>  I can think of a few ways to do those endpoint-PEP channels, but if you want to talk to the client side as a PEP you’re going to very likely have NAT issues too,

Yes; they are easier when piggybacking ACKs, because this signaling traffic then shares the same tuple as the main traffic, but otherwise, NATs can prevent some use cases, and there is the problem of identifying the “main” traffic the SC is talking about. Again multiple design choices there...

> and I think(?) you might need to talk to the client side to do a good job as a pep.  At very least if you want retransmits after downstream loss to be a part of this story, but probably also if you want to be able to drain the pep’s queue in a reasonable way.

That really depends on the use case.

>  So maybe you have to successfully talk to the server first (which a PEP could maybe do on a well-known port on the sender’s IP, offering a client cert to identify itself so servers can do some vetting?)

Yes…

> and the server could relay the PEP’s server name to the client so it could open a connection and get the channel it needs as well?

Aha; maybe?

>   I’m not sure.  I don’t offhand see another way for the PEP to reach the client thru a NAT unless it injects something in the target stream in a way that passes the NAT, which seems... probably trickier.

I don’t think the client always needs to be involved to be able to do some good with this. As I tried to illustrate with the two use cases, what needs to change really depends on the case it is.

> Anyway, very interesting question.  I do hope there’s a good answer here, and thanks Michael and Keith for raising it, you’ve definitely got me thinking.

Thanks for the feedback! :)

> PS: I think some PEPs operate as a 2-ended tunnel over (for instance) a satellite link, rather than a single on-path node.  I think some possible approaches here won’t care, but others might.

Aha - with tunneling, the problem above probably goes away, yes…

Cheers,
Michael

> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Mar 2022 15:17:53 +0100

Hi,

A separate email to keep the thread alive, since Spencer wanted to discuss multipath:

1) how could it support MP:  I didn’t have it on the slides, but “you can split traffic for me on the path, I can handle some HOL blocking delay on this connection” could be another type of use case for this protocol…

2) How would it interact with multipath:  Say, a SC proxy just starts ACKing back towards the source (consider a case with no NAT, or the SC proxy sitting before it, or ACKs being piggybacked: then the NAT is also less of a problem). The path changes => the SC disappears; no more ACKs, no more performance improvement. Or, there is SC proxy 2, which all of a sudden begins ACKing - supported in the same way. Perhaps a setup round-trip is wasted before these ACKs on a new path could become useful…

Multiple SCs on multiple paths…. well they would ACK each, e.g. feeding into the congestion control as per-path information. SC ACKs from only one path out of multiple in a MP connection - at least in case of MPTCP, this would refer to the “connection” it sees (how to identify that is another open issue … but let’s keep it simple and say “piggyback on the connection that it sees” - so it would be specific to only one path, perhaps...

Surely not all cases are so easy  :)

Cheers,
Michael

---

From: Nicolas Kuhn <[email-masked]>
Date: Thu, 24 Mar 2022 18:14:30 +0100

Hi,

On the interactions between a proxy and multi-path protocols, here is a
pointer to experiments we had done with PEPSal splitting TCP connections
and MP-TCP.
https://datatracker.ietf.org/meeting/106/materials/slides-106-mptcp-mptcp-satellite-01

The TCP splitting proxy should be aware that the end-to-end protocol is
trying to negotiate a multi-path connection otherwise there may be issues.

We had also experienced issues related to the receive buffer management
(expected to be located at the client only with MPTCP) and MPTCP-level
acknowledgement or packets.

Moreover, with QUIC the multipath extension negotiation would hardly be
seen by a proxy, right ?

As you said, Michael, the devil is in the details and this opens the room
for very interesting research IMHO.

Thanks for sharing this work,

Nico

On Thu, Mar 24, 2022 at 3:18 PM Michael Welzl <[email-masked]> wrote:

> 1) how could it support MP:  I didn’t have it on the slides, but “you can
> split traffic for me on the path, I can handle some HOL blocking delay on
> this connection” could be another type of use case for this protocol…
>
> 2) How would it interact with multipath:  Say, a SC proxy just starts
> ACKing back towards the source (consider a case with no NAT, or the SC
> proxy sitting before it, or ACKs being piggybacked: then the NAT is also
> less of a problem). The path changes => the SC disappears; no more ACKs, no
> more performance improvement. Or, there is SC proxy 2, which all of a
> sudden begins ACKing - supported in the same way. Perhaps a setup
> round-trip is wasted before these ACKs on a new path could become useful…
>
> Multiple SCs on multiple paths…. well they would ACK each, e.g. feeding
> into the congestion control as per-path information. SC ACKs from only one
> path out of multiple in a MP connection - at least in case of MPTCP, this
> would refer to the “connection” it sees (how to identify that is another
> open issue … but let’s keep it simple and say “piggyback on the connection
> that it sees” - so it would be specific to only one path, perhaps...
>
> *From: *Spencer Dawkins at IETF <[email-masked]>
> *Date: *Thu,2022-03-24 at 5:44 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[PANRG] About Michael's proposal on sidecar protocols in PANRG
> today
>
> Dear PANRG,
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 24 Mar 2022 23:50:14 +0100

Hi,

Changing the subject line too, to be more correct; some answers below:

> On Mar 24, 2022, at 6:14 PM, Nicolas Kuhn <[email-masked]> wrote:
> 
> Hi, 
> 
> On the interactions between a proxy and multi-path protocols, here is a pointer to experiments we had done with PEPSal splitting TCP connections and MP-TCP. 
> https://datatracker.ietf.org/meeting/106/materials/slides-106-mptcp-mptcp-satellite-01 <https://datatracker.ietf.org/meeting/106/materials/slides-106-mptcp-mptcp-satellite-01> 

*** Commercial interlude ***   please use PEP-DNA instead: https://github.com/kr1stj0n/pep-dna <https://github.com/kr1stj0n/pep-dna>   faster, in the kernel, able to relay the handshake (i.e., no need for it to terminate before beginning the next), also open source…    :-)

> The TCP splitting proxy should be aware that the end-to-end protocol is trying to negotiate a multi-path connection otherwise there may be issues. 
> 
> We had also experienced issues related to the receive buffer management (expected to be located at the client only with MPTCP) and MPTCP-level acknowledgement or packets. 

These *may* be relevant, but I would like to caution against translating problems seen with connection-splitting PEPs in these scenarios 1:1 into the scenarios with the sidecar.

A TCP connection splitter helps to easily explain the idea of separating congestion control, but the comparison fits only to a certain degree - there are some fundamental differences. For one, a TCP connection splitting PEP has to guarantee reliability, retransmit packets, etc., as it breaks TCP’s reliability semantics. That’s different in the use case that I showed, which it’s more minimalist (or “less intrusive”, for a better sounding phrase  :-)   hmmm… perhaps even better: "minimally invasive”, as in surgery?).

> Moreover, with QUIC the multipath extension negotiation would hardly be seen by a proxy, right ? 

Yes, that’s right. The SC proxy might not know that multipath is even in use… does it need to know about it though?

> As you said, Michael, the devil is in the details and this opens the room for very interesting research IMHO.
> 

Thanks for these kind words!

Cheers,
Michael

> 
> Nico
> 
> On Thu, Mar 24, 2022 at 3:18 PM Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>> From: Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/panrg <https://www.irtf.org/mailman/listinfo/panrg>
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/panrg <https://www.irtf.org/mailman/listinfo/panrg>

---

From: Nicolas Kuhn <[email-masked]>
Date: Fri, 25 Mar 2022 09:33:25 +0100

Hi,

On Thu, Mar 24, 2022 at 11:50 PM Michael Welzl <[email-masked]> wrote:

> *** Commercial interlude ***   please use PEP-DNA instead:
> https://github.com/kr1stj0n/pep-dna   faster, in the kernel, able to
> relay the handshake (i.e., no need for it to terminate before beginning the
> next), also open source…    :-)
>
> Interesting commercial interlude !

> These *may* be relevant, but I would like to caution against translating
> problems seen with connection-splitting PEPs in these scenarios 1:1 into
> the scenarios with the sidecar.
>
>

> A TCP connection splitter helps to easily explain the idea of separating
> congestion control, but the comparison fits only to a certain degree -
> there are some fundamental differences. For one, a TCP connection splitting
> PEP has to guarantee reliability, retransmit packets, etc., as it breaks
> TCP’s reliability semantics. That’s different in the use case that I
> showed, which it’s more minimalist (or “less intrusive”, for a better
> sounding phrase  :-)   hmmm… perhaps even better: "minimally invasive”, as
> in surgery?).
>
> Fair enough. I did not mean to translate non relevant problems for your
proposal.  I just wanted to point out that the level of intrusion is
something interesting to discuss.

> Yes, that’s right. The SC proxy might not know that multipath is even in
> use… does it need to know about it though?
>
> I have to think this through. I feel it depends on what the SC proxy
actually does - I need to look carefully at your proposal first ! In
general, if the proxy start doing things that the server expected the
client to do, there may be issues ?

Thanks,

Nico

>> *Subject: *[PANRG] About Michael's proposal on sidecar protocols in
>> PANRG today
>>
>> Dear PANRG,
>>
>> I liked Michael's proposal, and I suggest that we spend some time
>> thinking about interaction with multiplath, now that all REAL transport
>> protocols support multipath ... 😀
>>
>> Best,
>>
>> Spencer

---

From: Nicolas Kuhn <[email-masked]>
Date: Fri, 25 Mar 2022 09:55:03 +0100

Hi,

This looks like an interesting way of solving the E2E encryption and PEP
dilemma that deserves to be looked at.

In the SATCOM use-case, you mention that the SC can influence the sending
rate (slide 8).
While this may "solve" one of the problems PEP try to resolve (exploit the
adequate rate), PEP are interesting for other aspects : increasing endpoint
sending buffer sizes, local loss recovery or "slowstart" convergence.
It could be interesting to look at these aspects and in particular the
required interaction between the SC interaction with the E2E encrypted
traffic.

Also, in most SATCOM scenarios, there are two TCP-PEP proxies in sequence.

The approach is very interesting and I would be happy to read more about
this.

Cheers,

Nico

On Thu, Mar 24, 2022 at 3:06 PM Michael Welzl <[email-masked]> wrote:

> On Mar 24, 2022, at 2:40 PM, Holland, Jake <
> jholland=[email-masked]> wrote:
>
> Hi Panrg and Spencer,
>
> Keith & Michael’s !   Importantly, Keith deserves the credit for splitting
> this off into a separate protocol, which is the really main deal here IMO.
>
>
> I’m still not quite sure yet.  To me the tricky-sounding parts go beyond
> multipath (though multipath can certainly be a stopper or complication for
> some potential solutions).
>
> Stuff I like:
>
>    - I think it makes great sense in general to find a way to give the
>    endpoints some kind of hint and ongoing guidance saying “your end-to-end
>    congestion controller is probably going to be making deeply stupid
>    performance choices unless you listen to me”, which I think(?) is roughly
>    the core purpose of a PEP.
>    - I also think the hash-based acking of packets (I think at the UDP
>    payload layer?) is a natural mechanism to do that with, once you’ve got the
>    endpoint<->PEP communication channels you’d need.
>
>
> Stuff I’m unsure of:
>
>    - The part about how to get the endpoint-PEP communication channels
>    you’d need sounds tricky
>    - I’m not so sure about ignoring multiple on-path PEPs.  If you want
>    to handle both satellite and microwave, it’d be nice not to declare that
>    out of scope too early.  (I won’t insist on including it in the end if
>    there’s an otherwise good proposal that can’t do that, but I would prefer
>    answers to “how to do the endpoint-PEP communication” that don’t make this
>    impossible, if there are multiple answers that are approximately equally
>    good.)
>
>
> So we all agree that there are some tricky things to work out - and that’s
> even with only a single SC proxy. Sure, supporting multiple would be nice,
> but … you don’t even need to consider multipath to see problems with this.
> First, SC proxy 2 ACKs to SC proxy 1 about a specific flow X. Then, flow X
> doesn’t even traverse SC proxy 1 anymore, only SC proxy 2. How would SC
> proxy 2 know?
>
>  I can think of a few ways to do those endpoint-PEP channels, but if you
> want to talk to the client side as a PEP you’re going to very likely have
> NAT issues too,
>
>
> Yes; they are easier when piggybacking ACKs, because this signaling
> traffic then shares the same tuple as the main traffic, but otherwise, NATs
> can prevent some use cases, and there is the problem of identifying the
> “main” traffic the SC is talking about. Again multiple design choices
> there...
>
>
> and I think(?) you might need to talk to the client side to do a good job
> as a pep.  At very least if you want retransmits after downstream loss to
> be a part of this story, but probably also if you want to be able to drain
> the pep’s queue in a reasonable way.
>
>
>  So maybe you have to successfully talk to the server first (which a PEP
> could maybe do on a well-known port on the sender’s IP, offering a client
> cert to identify itself so servers can do some vetting?)
>
>
> Yes…
>
>
> and the server could relay the PEP’s server name to the client so it could
> open a connection and get the channel it needs as well?
>
>
> Aha; maybe?
>
>
>   I’m not sure.  I don’t offhand see another way for the PEP to reach the
> client thru a NAT unless it injects something in the target stream in a way
> that passes the NAT, which seems... probably trickier.
>
>
> I don’t think the client always needs to be involved to be able to do some
> good with this. As I tried to illustrate with the two use cases, what needs
> to change really depends on the case it is.
>
>
>
> Anyway, very interesting question.  I do hope there’s a good answer here,
> and thanks Michael and Keith for raising it, you’ve definitely got me
> thinking.
>
>
> PS: I think some PEPs operate as a 2-ended tunnel over (for instance) a
> satellite link, rather than a single on-path node.  I think some possible
> approaches here won’t care, but others might.
>
>

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 25 Mar 2022 08:56:41 +0000

> From: Michael Welzl <[email-masked]>
> Date: Thu,2022-03-24 at 3:50 PM

It seems relevant to some of the MP-QUIC statements about
congestion control.

If MP-QUIC lands on the LIA or OLIA stuff, then for a shared path
upstream of the PEP, the CC would react appropriately I think, but
for a shared path downstream of the PEP where the PEP doesn't know
about MP or the cwnd of other sub-flows, the PEP's transmit would
presumably(?) hit the same problems that drove OLIA's development,
I think.

Traditionally of course a TCP PEP would just ignore this, since
it's kind of doing an undocumented hack anyway.  But with all the
explicit communication with the PEP in this scenario it might be
possible to do something, which might either make the docs (and
perhaps even the implementations and the signaling) somewhat more
complex or force a doc to acknowledge that the RFC series's views
on congestion control can be a bit of a naive fiction these days
in some regards (or both).

-Jake

---

From: Michael Welzl <[email-masked]>
Date: Fri, 25 Mar 2022 11:58:15 +0100

> On Mar 25, 2022, at 9:55 AM, Nicolas Kuhn <[email-masked]> wrote:
> 
> Hi, 
> 
> This looks like an interesting way of solving the E2E encryption and PEP dilemma that deserves to be looked at. 
> 
> In the SATCOM use-case, you mention that the SC can influence the sending rate (slide 8).  
> While this may "solve" one of the problems PEP try to resolve (exploit the adequate rate), PEP are interesting for other aspects : increasing endpoint sending buffer sizes, local loss recovery or "slowstart" convergence. 
> It could be interesting to look at these aspects and in particular the required interaction between the SC interaction with the E2E encrypted traffic. 
> 

In a general scenario, there may be no way to do this without tunneling. Yet, maybe in SATCOM scenarios, it’s possible to simply rely on the fact that there are multiple proxies on the path for sure?  Anyway, a SC proxy would have to be configured to do something specific for the path in use, just like today’s PEPs are…  maybe it’s just a matter of making this a configurable behavior.

> The approach is very interesting and I would be happy to read more about this. 

Thanks!  :)

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 25 Mar 2022 15:02:41 +0100

Snip - and combining two MP-related emails together in a single answer:

[From Nicolas]

> I have to think this through. I feel it depends on what the SC proxy actually does - I need to look carefully at your proposal first ! In general, if the proxy start doing things that the server expected the client to do, there may be issues ?

No, to the server, it would be very clear what’s happening. Nothing hidden, no transparent proxying - that’s a big part of the point here.

[From Jake]

> On Mar 25, 2022, at 9:56 AM, Holland, Jake <[email-masked]> wrote:
> 

Aha. Well, to begin with, to a LIA or MPTCP sender-side CC instance, things would seem normal: they would be delivered ACKs per path, and know what to do with them.
If, then, the SC proxy would carry out its own congestion control downstream (like in use case #1 that I showed), then… yes there would be fairness problems, much like today’s MPTCP CC would get its fairness wrecked by a downstream connection-splitting PEP operating on only one of its subflows. If that’s a bit problem in practice is another question…   I mean, if you try to make a transport work through a special link where e2e CC just doesn’t cut it (e.g., because the link’s capacity fluctuates), then you already face quite different problems than the long-term fairness between MPTCP sub-flows.
Like, your cwnd has just been cut to almost nothing, and now capacity is available again: what’s the point of long-term (O)LIA fairness when, by the time your flow finishes, you just can’t get up to the available capacity anyway?

> it's kind of doing an undocumented hack anyway.

exactly -

>  But with all the

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

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 25 Mar 2022 15:37:44 +0100

Apologies, I should have proof-read this email before sending:

> Aha. Well, to begin with, to a LIA or MPTCP sender-side CC instance,

Of course I meant “LIA or OLIA MPTCP sender-side CC instance”, and:

> things would seem normal: they would be delivered ACKs per path, and know what to do with them.
> If, then, the SC proxy would carry out its own congestion control downstream (like in use case #1 that I showed), then… yes there would be fairness problems, much like today’s MPTCP CC would get its fairness wrecked by a downstream connection-splitting PEP operating on only one of its subflows. If that’s a bit problem in practice is another question…

of course I meant a “big” problem.

Cheers,
Michael

>   I mean, if you try to make a transport work through a special link where e2e CC just doesn’t cut it (e.g., because the link’s capacity fluctuates), then you already face quite different problems than the long-term fairness between MPTCP sub-flows.

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 25 Mar 2022 17:51:30 +0000

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

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

HTH.

-Jake

---

From: Michael Welzl <[email-masked]>
Date: Fri, 25 Mar 2022 20:32:54 +0100

> On Mar 25, 2022, at 6:51 PM, Holland, Jake <[email-masked]> wrote:
> 

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.

> some important new understanding about concerns in path-aware

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