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

"Holland, Jake" <jholland@akamai.com> Fri, 25 March 2022 08:56 UTC

Return-Path: <jholland@akamai.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 92E303A113F for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 01:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 fbK9NlxleoEb for <panrg@ietfa.amsl.com>; Fri, 25 Mar 2022 01:56:52 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1B1DF3A113D for <panrg@irtf.org>; Fri, 25 Mar 2022 01:56:48 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22P8PHBE019439; Fri, 25 Mar 2022 08:56:43 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0HlwpU7OJ03n531VAAGfgxZneVI9QKbyenf8fRdEF8I=; b=I4Vb4CL8jUuIR09S5CCYfHFmHg6dFtSG6aTIKlFD1KCnlGO+qLJQe22JCwPwDEWwfRjh ObtinLUhbrNDztQn6TJd2CvXhc9kihdmZNfMUkWl0r/I3xYXpgdEHNWI1RkQ6wPF8M4V WwgRH5nTsCD/rJN85bpArgMGY+oxWmDB2coocqod+56v5sIp2JGi3G64A57ktz9jUIPK xredbmDnJEY/5lIpwKoppuq5l8WJDclKF0c2KhAddHi0UCB57mHjh4ujK700L9dKme8M +kW+adV51781gK9Anw96rk0DugvtcpCYfzN0B1o6WUDZ77vWoYzex6w4FfrqO6humoL5 dg==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3f0vkuj5d1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Mar 2022 08:56:43 +0000
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 22P8nvmo023975; Fri, 25 Mar 2022 01:56:42 -0700
Received: from email.msg.corp.akamai.com ([172.27.91.20]) by prod-mail-ppoint5.akamai.com with ESMTP id 3ewd5b175w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Mar 2022 01:56:41 -0700
Received: from usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) by usma1ex-dag4mb7.msg.corp.akamai.com (172.27.91.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.5; Fri, 25 Mar 2022 04:56:41 -0400
Received: from usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 25 Mar 2022 04:56:41 -0400
Received: from usma1ex-dag3mb5.msg.corp.akamai.com ([172.27.123.55]) by usma1ex-dag3mb5.msg.corp.akamai.com ([172.27.123.55]) with mapi id 15.00.1497.033; Fri, 25 Mar 2022 04:56:41 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: Michael Welzl <michawe@ifi.uio.no>, Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
CC: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>
Thread-Topic: [PANRG] About Keith and Michael's proposal on sidecar protocols in PANRG today
Thread-Index: AQHYP9GUsz1IlfnJRUC7FYrfTalWv6zPmo+A
Date: Fri, 25 Mar 2022 08:56:41 +0000
Message-ID: <9E79D1BE-D591-47FC-902E-A2DFB9B57604@akamai.com>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.58.22021501
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F145D414E6BD9D42A5BEBEB739FBF91E@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-25_02:2022-03-24, 2022-03-25 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203250048
X-Proofpoint-GUID: kgyAUKsVQ6_RZRTwaHxZR3plP6-tPJ_2
X-Proofpoint-ORIG-GUID: kgyAUKsVQ6_RZRTwaHxZR3plP6-tPJ_2
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-25_02,2022-03-24_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 clxscore=1011 malwarescore=0 spamscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203250049
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/rsPcqU4jmreHsjFaNrnuLJfSvXo>
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:56:57 -0000

> From: Michael Welzl <michawe@ifi.uio.no>
> Date: Thu,2022-03-24 at 3:50 PM
>> 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?

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