IETF Logo Mail Archive

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

Michael Welzl <michawe@ifi.uio.no> Thu, 24 March 2022 14:18 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 A27293A0C52 for <panrg@ietfa.amsl.com>; Thu, 24 Mar 2022 07:18: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, HTML_MESSAGE=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 UwtdZLJRIJi1 for <panrg@ietfa.amsl.com>; Thu, 24 Mar 2022 07:18:03 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 F2BCA3A0C5D for <panrg@irtf.org>; Thu, 24 Mar 2022 07:18:02 -0700 (PDT)
Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.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 1nXOHj-00CEvW-Mj; Thu, 24 Mar 2022 15:17:55 +0100
Received: from dhcp-9a5b.meeting.ietf.org ([31.133.154.91]) by mail-mx01.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 1nXOHi-00069W-Pc; Thu, 24 Mar 2022 15:17:55 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <51875E18-6905-474F-A384-580F9F3E72FD@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_24107B04-0F59-4E7A-8A72-AAE749AA7744"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Thu, 24 Mar 2022 15:17:53 +0100
In-Reply-To: <8F38CA66-7AA6-4DCF-88A6-30D0E38C80DF@akamai.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>
To: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>
References: <CAKKJt-c2K1B6mBeKuBmf+E+m+3ZPyTMRk-oZ23ZOP2hZHSkpPQ@mail.gmail.com> <8F38CA66-7AA6-4DCF-88A6-30D0E38C80DF@akamai.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 31.133.154.91 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.154.91; envelope-from=michawe@ifi.uio.no; helo=dhcp-9a5b.meeting.ietf.org;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: B621ADCDD124497A562035D8E452453897E57A4E
X-UiOonly: 431CA4BD2CFA64FF513E06D027546B26F7277FC0
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/jjh5bwFbwda_m9oEbTBJPFxj6Oc>
Subject: Re: [PANRG] About 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: Thu, 24 Mar 2022 14:18:08 -0000

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

v2.23.0 | Report a Bug | By Email