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

Hi,

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

> On Mar 24, 2022, at 6:14 PM, Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com> 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 sharing this work,

Thanks for these kind words!

Cheers,
Michael

> 
> Nico
> 
> On Thu, Mar 24, 2022 at 3:18 PM Michael Welzl <michawe@ifi.uio.no <mailto: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 <mailto:spencerdawkins.ietf@gmail.com>>
>> Date: Thu,2022-03-24 at 5:44 AM
>> To: "panrg@irtf.org <mailto:panrg@irtf.org>" <panrg@irtf.org <mailto: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 <mailto:Panrg@irtf.org>
>> https://www.irtf.org/mailman/listinfo/panrg <https://www.irtf.org/mailman/listinfo/panrg>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org <mailto:Panrg@irtf.org>
> https://www.irtf.org/mailman/listinfo/panrg <https://www.irtf.org/mailman/listinfo/panrg>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg