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

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 <michawe@ifi.uio.no> wrote:

> 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: *Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> *Date: *Thu,2022-03-24 at 5:44 AM
> *To: *"panrg@irtf.org" <panrg@irtf.org>
> *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
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>
>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>