Re: Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QU IC for ATSSS"]

Olivier Bonaventure <olivier.bonaventure@tessares.net> Thu, 02 April 2020 09:25 UTC

Return-Path: <olivier.bonaventure@tessares.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A192A3A0E4B for <quic@ietfa.amsl.com>; Thu, 2 Apr 2020 02:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 kCERV0EQou4q for <quic@ietfa.amsl.com>; Thu, 2 Apr 2020 02:25:49 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4FE0F3A0E47 for <quic@ietf.org>; Thu, 2 Apr 2020 02:25:48 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id s8so1152210wrt.7 for <quic@ietf.org>; Thu, 02 Apr 2020 02:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dMsrSLD0PYPsUdami4iRvTsMcFqSn29T+0Cfsd5kEOc=; b=hloEM3GSAI/Bi7Ni8tDIOyLyueqCjD102W4o3mujr8+EEe/dIBC8Klc7qFqpoiR8am 7WwCEww0P5w8/Scb0X5M/KcS3I0iuxWiLzi+9WLZbWdaI3B8G7InJUt+synScSYLgu0W F3Yi1ViT/3/CVV5JCxWPzzeJrNB33Po1MygORDMzda5golHca0wf5mNdn3e7pjzEqoEy N7doj2ZEpXVUaVfwqKzQ13S/us4oot0zhkN5BAAWtwUfGaY+EwwPz9JPszOcbHt+NgxE eXm92zQUYRBlAunh9cwnqawwgQnia6l7Fnqg3et0CfWSvBtokdmxyRdysperwrErVLp0 FheQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dMsrSLD0PYPsUdami4iRvTsMcFqSn29T+0Cfsd5kEOc=; b=VA3WOD9FS/kaBv22HVCz5HPCRmkRop3yvysHeyg9XZ7npxWFmznKKV1lS3wqfV+sQU 5JE3Lp5F+jFGUZFEHyrTHOSFXp6p9Xs5xoDppTZa7G0eECyuglMH+XW+O0tpYGfDrpgJ s6K/TApaYVfBtUyxe1/oF8OQM4sV4ccZo+/o8Hp8tEwt5Djgpe0zjGk+tdwf+7QmlXa2 BtoJV+JpPg5YNzB40nZEexOc8zGW3NZlHXprLKVGO1679dfFBloQP3E7ihvflfXLe2GC UsfWXxTgUVYl8vPKgFMtMiTl05pAsmX/5X+VIYKod6+jRXAIYT+4XtuxHbRMc6xXflxK NOWg==
X-Gm-Message-State: AGi0PuYgjRNosUCJ2d99Rj4bc+WADViPZlzmYRmkz2TrNZ+ehFWeJT/3 C6IL7yWQfIBV1duFPDGt0qvVL5qZvIh0XzglN3cNGi9JLYjM5ErwuRL8zLDHr5lm5iW7nCoyTvQ 4ww==
X-Google-Smtp-Source: APiQypJi5naOLYwzBDu4yLqQwTg3QoTpD8auYUk6K9xcXw70FLsqGtw4Cak02exPe5Jtg28Um/Cs3w==
X-Received: by 2002:adf:fd44:: with SMTP id h4mr2533984wrs.177.1585819547228; Thu, 02 Apr 2020 02:25:47 -0700 (PDT)
Received: from host.dynamic.voo.be ([2a02:2788:484:b4f:21d7:382a:55c3:26cf]) by smtp.gmail.com with ESMTPSA id f12sm6207697wmh.4.2020.04.02.02.25.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 02:25:46 -0700 (PDT)
From: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Message-Id: <C5650B2A-974F-468D-A0A1-B5C27E47E837@tessares.net>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Re: =?UTF-8?Q?Re:_[Fwd:_New_Liaison_Statement, _"LS_on_need_for_Multi-Path_QU?= IC for ATSSS"]
Date: Thu, 02 Apr 2020 11:25:44 +0200
In-Reply-To: <14c8e8d3-1c93-408c-80d5-4fc298b42583@www.fastmail.com>
Cc: quic@ietf.org
To: Martin Thomson <mt@lowentropy.net>
References: <158575376802.30598.14992202513752114049@ietfa.amsl.com> <53440b6005987fe7b3608186a48428d626d92422.camel@ericsson.com> <14c8e8d3-1c93-408c-80d5-4fc298b42583@www.fastmail.com>
X-Mailer: Apple Mail (2.3445.104.14)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D62D8824-091D-4D73-AE8D-AD14C10B2236"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/M4O8SfgdFKFC0wTCa78nvGxJhP0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 09:25:52 -0000

Martin,

> On 2 Apr 2020, at 01:56, Martin Thomson <mt@lowentropy.net> wrote:
> 
> If I read this liaison correctly, this is effectively a request to keep 3GPP in the loop.  The request to do multipath is more implied than anything else.  I think that the explicit request is fine.  The implicit one maybe less so.
> 
> I suspect that work here would go faster if we had more input on the hard multipath problems.  That's not the spelling of the protocol (that's almost trivial, as demonstrated in proposals), but the assignment of different information elements paths that might have different characteristics.  What I heard in Zürich was that this was less of an engineering problem than a research one.
> 
> I'd be interested in having active engagement from people who have use cases. Specifically, I would seek to learn whether this is truly a research question or whether there are simplifying assumptions that might make the problem tractable for some use cases.

Since the publication of Multipath TCP in RFC6824, we have accumulated experience in deploying and operating solutions that leverage multipath transport. Here are a few pointers to documents that describe these deployments. Several of the people that were involved in multipath TCP and also active in QUIC and can bring their experience to finalise multipath extensions to QUIC.

https://www.ietfjournal.org/multipath-tcp-deployments/ <https://www.ietfjournal.org/multipath-tcp-deployments/>
https://tools.ietf.org/html/rfc8041 <https://tools.ietf.org/html/rfc8041>
https://arxiv.org/abs/1907.04570 <https://arxiv.org/abs/1907.04570>

I can provide additional information for some of these use cases

> The more I think on this subject, the more that I think it was a mistake to charter to do multipath.  I don't believe that we properly answered the standard BoF questions with respect to this topic.

I disagree. Given the flexibility of QUIC, it would be a mistake to not consider multipath. TCP should have been a multipath protocol from day one.


Olivier



-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>