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

Michael Welzl <michawe@ifi.uio.no> Fri, 25 March 2022 14:38 UTC

Return-Path: <michawe@ifi.uio.no>
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 B05293A11E1 for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 07:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 qMXUWawlY6yY for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 07:38:04 -0700 (PDT)
Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864BF3A116F for <panrg@irtf.org>; Fri, 25 Mar 2022 07:37:56 -0700 (PDT)
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <michawe@ifi.uio.no>) id 1nXl4V-004eXn-5F; Fri, 25 Mar 2022 15:37:47 +0100
Received: from dhcp-96d5.meeting.ietf.org ([31.133.150.213]) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from <michawe@ifi.uio.no>) id 1nXl4U-000CRZ-0V; Fri, 25 Mar 2022 15:37:47 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <E878878B-EA80-42C1-9529-82BB4EE513A9@ifi.uio.no>
Date: Fri, 25 Mar 2022 15:37:44 +0100
Cc: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D98E0D0-4A2D-4309-AF21-48C420480AA3@ifi.uio.no>
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> <CAL0D2oRdbrpKCFBxTTqSVN820KM_Yrkkx5an+gZLfnwcfzqM6w@mail.gmail.com> <E878878B-EA80-42C1-9529-82BB4EE513A9@ifi.uio.no>
To: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 31.133.150.213 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.150.213; envelope-from=michawe@ifi.uio.no; helo=dhcp-96d5.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.009, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 440A90F2DC1D84069496D6AFA88B041410D7722C
X-UiOonly: 2BB57EA998B7B86A961D64F0259D05EF8A026107
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/mtV6Q5CXF2-XzHG2xYwq_kDmB7Q>
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 14:38:17 -0000

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.
> 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?
> 
> 
>> Traditionally of course a TCP PEP would just ignore this, since
>> it's kind of doing an undocumented hack anyway.
> 
> exactly -
> 
> 
>>  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).
> 
> 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
> 
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg