From nobody Mon Nov 23 10:00:06 2020 Return-Path: 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 0E16D3A0BDE for ; Mon, 23 Nov 2020 10:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 ye7JtevxjjLp for ; Mon, 23 Nov 2020 10:00:03 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 214F63A0BE3 for ; Mon, 23 Nov 2020 10:00:03 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id o71so16754671ybc.2 for ; Mon, 23 Nov 2020 10:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KQGtWNxZLLbIucvVBemD5lvve850pdFRsXoqYGUCvcQ=; b=gRwiplGGgJt0PPBJ3ovSv8i/lUOomKKs3h/ZXerykyPF6CwvkRezd1w7XWZN9a/3CO /TIJ8Wv9OkEZuJyzc/Bo0who6Fmtm3RhcxU/X/n33Fy9MwiT1m3LB7A59ookeSNDlMCF a288wk5j9qj28A69aPIR9CxoDvHfJQJbht/afJiSJ7ubNMCdIVo+IUsy5jflCx58n2vG cH1zXAKXq8L1a7t19hhBSgD2yOl57YGE8gW6iH22A63GsScBbpGy8s6qv6kKV8OSmDn9 kwOgFv3Fy8/yeP/3ypVWejDuSG4dXLIq+upC0EjHk26/9hyIOpupHnoteXVTlJv//cid OFxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KQGtWNxZLLbIucvVBemD5lvve850pdFRsXoqYGUCvcQ=; b=gspIvX8Lur96aU0CeptaSDvtNNRw/gjCRzlqeZXD+LHlhKHLYlYxmuaxbWH6z3IaMH /R1Q10HomgyKaxTSkpkSNZbM7uKiRXa35ZUG99IuG6xKrDSRGYPGT/JibRkdOR+7rfKX 4gcEjFf2FCYBjj6YXHqe/ZvxdGoDx12eoaDQTohdBHgycTRcCy7RSdIZBrfGb+nBZb1I /eRk1V1LEj5lai9jlt7+KhjvMpgzcf2SpsKdK9SXI/9j/vA95zhnqHtHmnigiKLfjS/i OjO5JK5dd+8X2NI5iwrLwSPbV9spOlpFp7SQc3KuAtiY+RNORRQiCsg4GepP3lTbbO1d MT5A== X-Gm-Message-State: AOAM532pCLZl0+WijKPNUkr0UWa24u4DwsLHcB8TTtmX4oHRxLptfB1b +VcMVP3bSlL8jnUgZrtc2C+W1IjtSoZT8mm1eWg= X-Google-Smtp-Source: ABdhPJxy11ZYBg3YdKa2s7zXRN50fM6/DRR6K/xnA8OUVURNZzvgflw8yYe8kVHtMq6t0yP38fqbohy2R9U1cJYMLhE= X-Received: by 2002:a25:ae53:: with SMTP id g19mr817648ybe.288.1606154402410; Mon, 23 Nov 2020 10:00:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 23 Nov 2020 11:59:36 -0600 Message-ID: Subject: Re: Next steps for Multipath QUIC To: Lucas Pardue Cc: "Flinck, Hannu (Nokia - FI/Espoo)" , QUIC WG Content-Type: multipart/alternative; boundary="0000000000009c35cd05b4c9f6f1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:00:05 -0000 --0000000000009c35cd05b4c9f6f1 Content-Type: text/plain; charset="UTF-8" Hi, Lucas, On Mon, Nov 23, 2020 at 9:52 AM Lucas Pardue wrote: > Hey Hannu, Spencer, > > > On Mon, Nov 23, 2020 at 2:23 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hannu, >> >> On Mon, Nov 23, 2020 at 3:02 AM Flinck, Hannu (Nokia - FI/Espoo) < >> hannu.flinck@nokia-bell-labs.com> wrote: >> >>> There seems to be three different approaches for multipath support, if I >>> am not missing any: >>> >>> https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ >>> https://datatracker.ietf.org/doc/draft-an-multipath-quic/ >>> https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ >>> >>> Each of them addressing different use cases. It is not obvious to me >>> that the experimentation would lead into single design rather than debate >>> between the approaches. >>> I would expect as the outcome of the experimentations deeper >>> differences between the multipath mechanisms tailored for respective use >>> cases. How can we draw any generic conclusions from such results? How would >>> you compare the outcomes? >>> >> >> I agree with you on your question. >> >> I'm working to catalog the various strategies we've talked about in QUIC, >> in >> https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-02#section-2.3 >> . >> >> Speaking only for myself, I don't anticipate one approach satisfying all >> of the use cases, which I'm thinking of in two categories: >> >> - The sender needs to control what to send next, and on what path, >> based on more knowledge of the paths and the application than a >> general-purpose transport scheduler can know, or >> - The sender is willing to delegate those decisions to a >> general-purpose transport scheduler, because that will be "good enough". >> >> Of course, I could be wrong about that. >> >> I look forward to hearing more about the experiments as we proceed. >> > > Speaking as an individual, I think experimental work towards proving or > disproving whether a single multipath QUIC design, within the set > constraints, can solve several multipath use cases is valuable. > I agree - sorry if I was unclear. My suspicion, to be confirmed or overturned, is that "several multipath use cases" may not mean "all of the proposed multipath use cases". Using my two categories above, I'll be looking especially closely to see if a single multipath QUIC design can address use cases in both categories. We'll see, of course. Best, Spencer --0000000000009c35cd05b4c9f6f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Lucas,=C2=A0

On Mon, Nov 23, 2020 at 9= :52 AM Lucas Pardue <lucas= pardue.24.7@gmail.com> wrote:
Hey Hannu, Spen= cer,


On Mon, Nov 23, 2020 at 2:23 PM Spencer= Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hannu,=C2=A0

On Mon, Nov 23, 2020 at 3:02 AM Flinck, Hannu (Nokia - FI/Espo= o) <hannu.flinck@nokia-bell-labs.com> wrote:
There seems to be three different approac= hes for multipath support, if I am not missing any:

=C2=A0https://datatracker.ietf.org/d= oc/draft-deconinck-quic-multipath/
https://datatracker.ietf.org/doc/draft-an= -multipath-quic/
https://datatracker.ietf.org/doc/dr= aft-huitema-quic-mpath-option/

Each of them addressing different use cases. It is not obvious to me that t= he experimentation would lead into single design rather than debate between= the approaches.
I would expect as the outcome of the experimentations=C2=A0 deeper differen= ces between the multipath mechanisms tailored for respective use cases. How= can we draw any generic conclusions from such results? How would you compa= re the outcomes?

I agree with you on y= our question.

I'm working to catalog the various str= ategies we've talked=C2=A0about in QUIC, in=C2=A0https://tools.ietf.org/html/draft-dawkins-quic-what-to= -do-with-multipath-02#section-2.3.

Speaking on= ly for myself, I don't anticipate one approach satisfying all of the us= e cases, which I'm thinking of in two categories:
  • The= sender needs to control what to send next, and on what path, based on more= knowledge of the paths and the application than a general-purpose transpor= t scheduler can know, or
  • The sender is willing to delegate those de= cisions to a general-purpose transport scheduler, because that will be &quo= t;good enough".=C2=A0
Of course, I could be wrong about = that.=C2=A0

I look forward to hearing more about t= he experiments as we proceed.=C2=A0

Speaking as an individual, I think experimental work towar= ds proving or disproving whether a single multipath QUIC design, within the= set constraints, can solve several multipath use cases is valuable.=C2=A0<= /div>

I agree - sorry if I was = unclear. My suspicion, to be confirmed or overturned, is that "several= multipath use cases" may not mean "all of the proposed multipath= use cases".=C2=A0=C2=A0

Using my two categor= ies above, I'll be looking especially closely to see if a single multip= ath QUIC design can address use cases in both categories.

We'll see, of course.=C2=A0

Best,

Spencer
--0000000000009c35cd05b4c9f6f1--