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

Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com> Fri, 25 March 2022 08:33 UTC

Return-Path: <nicolas.kuhn.ietf@gmail.com>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B83A10E1 for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 01:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTkn58zZktz0 for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 01:33:37 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706823A10C5 for <panrg@irtf.org>; Fri, 25 Mar 2022 01:33:37 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id t2so5921811qtw.9 for <panrg@irtf.org>; Fri, 25 Mar 2022 01:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oeaVyBeZ6fSSGdfd7LcAj9TTHf6mYLItV8lLRsYe3/8=; b=FZ5R5BvZETW/J7iATOEus0bcoxwKspD7bpuXOwB4pbNvHhKDQDyWhjN+bFLyTbtZK2 W09HuLKu7gMQ2LCb0K9knGzbXAUvF6rCVjlebvyRSjxh2aKSKSX26+l5YKrkJTZ1rBQm MKZboc/TGoXOOmzlJiIq5Vgw8gjL8XiJVmc1N7/tOAKfWz/fEUNAXys6DpCY/RXW+PWo s9iqcxWajRPVgxGttZTkCuk9Q530z5iGjlfrYVkt8f5+x0fOjEAIrlFEQvZvAV+6tGKY JCb3G1/7/J2SIYoLsB15HuNSGcNIK6l1pZgkUNQ8Ftk2FbbGPdBNgf2hGF9353HTTGWb vn3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oeaVyBeZ6fSSGdfd7LcAj9TTHf6mYLItV8lLRsYe3/8=; b=fBlFjOOYGfIjMWQa67itzNlOf3wr/G+KauUVWPykROLRWAbeTRQ21KCDq4Z2ok+zWJ GGZCd4aP3QdhUwdPIYGE4/Nc2GzJVGrhi/+R2qiprCaqKzOWoWpxRiH06oamrXT39sGV PYhM0q7azJ2CMA8wSqL4YWH7F7HEBRdaufr83Ro/fl3aX2Eriz+pNLFkmYleIl7jPxDQ 8qg6zHNOJRih/+WiGw6TxbwknsrWIy879h3DxAddQxSxxihO5cRM+8iwksaAjXNH4xuH TPgBQKtsOv0z8Jpq+ljJt/zk+FFciFX2fhCZgpw2Fs+tYoZn6AGyXFi5haC7jwSSbXbd 9cSw==
X-Gm-Message-State: AOAM533msaMva6qVfbx5b3ZBkFmG7LKAzztjfmpCgylWPGdeuJNr2mH2 ot2p5iPj2t6p9IifZct7qpaF9OB1g1PdqrbG2Mw=
X-Google-Smtp-Source: ABdhPJxsUsCD42DJlfEPd4TlbG3rB+UaATmUatdoJkQ/aypvwlbZwNGkdPoaxqq0ByYy1BtQ52Z/TyE+j8Px78ogeh4=
X-Received: by 2002:a05:622a:145:b0:2e1:b932:d019 with SMTP id v5-20020a05622a014500b002e1b932d019mr8236215qtw.46.1648197216126; Fri, 25 Mar 2022 01:33:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-c2K1B6mBeKuBmf+E+m+3ZPyTMRk-oZ23ZOP2hZHSkpPQ@mail.gmail.com> <8F38CA66-7AA6-4DCF-88A6-30D0E38C80DF@akamai.com> <51875E18-6905-474F-A384-580F9F3E72FD@ifi.uio.no> <CAL0D2oQgdLon5jYvRrcyRtQoNQmp66jcwOZ1OCa9rdPweuJC=Q@mail.gmail.com> <CBACE661-9BE9-4B93-BA27-6F237C4F0D63@ifi.uio.no>
In-Reply-To: <CBACE661-9BE9-4B93-BA27-6F237C4F0D63@ifi.uio.no>
From: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
Date: Fri, 25 Mar 2022 09:33:25 +0100
Message-ID: <CAL0D2oRdbrpKCFBxTTqSVN820KM_Yrkkx5an+gZLfnwcfzqM6w@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000096491605db06d153"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/jYNfEAT9UNnAMVp2PhNix_sSF98>
Subject: Re: [PANRG] About Keith and Michael's proposal on sidecar protocols in PANRG today
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2022 08:33:43 -0000

Hi,

On Thu, Mar 24, 2022 at 11:50 PM Michael Welzl <michawe@ifi.uio.no> wrote:

> 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
>
>
> *** 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 !


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

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


> 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> 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
>>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>
>
>