Re: Multi-path QUIC Extension Experiments
Robin MARX <robin.marx@uhasselt.be> Wed, 14 July 2021 14:31 UTC
Return-Path: <robin.marx@uhasselt.be>
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 AEE743A1AFB for <quic@ietfa.amsl.com>; Wed, 14 Jul 2021 07:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 (1024-bit key) header.d=uhasselt.be
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 n6CWhJJ6L4JH for <quic@ietfa.amsl.com>; Wed, 14 Jul 2021 07:31:49 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 67F603A1AF9 for <quic@ietf.org>; Wed, 14 Jul 2021 07:31:48 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id f17so3498278wrt.6 for <quic@ietf.org>; Wed, 14 Jul 2021 07:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SX5Y/ylhmrDRNCU9Z71zWcZgUK9kNgexL1IWWOrjXQE=; b=h/08QqRgi27qfvggoR+MGHo9mO5bzHfFOJzj/0qRFlKTzaWYlj3NuaCb7L6Rn8Y0iF jULVx7fc35+czj8rkKX5JPBDxHhN51ik2mjC6S4/NihQE8mGo+CRwvTYb8oE3Xb5G9lx Io4jRKXgyG0Z382GJ7ccdHsB15ZdG+CCXo7U0=
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=SX5Y/ylhmrDRNCU9Z71zWcZgUK9kNgexL1IWWOrjXQE=; b=KlPXbWhCjDvRZtR5vnrqFeguhHFGnmLPAokEnav3QsY0xiq7HMIayv60GsRjRBRf6h +Ofs/zccRHJtMN2WSYjszQv2KLFD7KTRoiELqI5FUMZAaS9cqPFkWwpNHyKHsKlhfStF MuaQ8aLambVyp3CgbcpaAryrwyiHeyaNGvYcUQlSdRWBrG5YXL95ox0pCFe5IuUbqqcf 61oSFfktvQC/kjIFltQK55lx0ybJ7rKMI3gefLdLxk0ATRS0x9gc8eOaOE55TFo+8yVZ bI14ZumxaG7P0NDRLhb5r5Bybtn0wVE+vhPLAztx9p7d7Uh3tjJGvRs6t1nP8TB/ch/i 9xBw==
X-Gm-Message-State: AOAM5328pMcwLTpKdG6V5gIQXJJ2AxvcwOlh7N1XlmfVliILHoQe0Flj QHU6FCQJFpOo0HFl+9Jxt0dSXR6zFVBJnsbEucrOLA==
X-Google-Smtp-Source: ABdhPJxPr5RzWdZyTFqZFWKjjtozPFTwxsZ5kTRuDxsiHPWS5sFUlCVf609Rzlyp+pmP4uHC1V7FURIg/oN6H8FHbPE=
X-Received: by 2002:adf:fd8a:: with SMTP id d10mr12445294wrr.108.1626273106822; Wed, 14 Jul 2021 07:31:46 -0700 (PDT)
MIME-Version: 1.0
References: <02fa8c41-4673-47b6-b245-19ab13cc3fad.miaoji.lym@alibaba-inc.com>
In-Reply-To: <02fa8c41-4673-47b6-b245-19ab13cc3fad.miaoji.lym@alibaba-inc.com>
From: Robin MARX <robin.marx@uhasselt.be>
Date: Wed, 14 Jul 2021 16:32:03 +0200
Message-ID: <CAC7UV9bXbVSy=RsBVecOw0feVGedUxo=wvHEFP-g+LDVOHDuGg@mail.gmail.com>
Subject: Re: Multi-path QUIC Extension Experiments
To: Yanmei Liu <miaoji.lym@alibaba-inc.com>
Cc: quic <quic@ietf.org>, Yunfei <yunfei.ma@alibaba-inc.com>, Christian Huitema <huitema@huitema.net>, AN Qing <anqing.aq@alibaba-inc.com>, 李振宇 <zyli@ict.ac.cn>, "matt.joras" <matt.joras@gmail.com>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d71f8505c7163633"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/odJeVeE8oAnzDq0_gMFdsSTCQI0>
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: Wed, 14 Jul 2021 14:31:56 -0000
Hello Yanmei, Thanks for the additional results on an interesting topic. I'm looking forward to reading the SIGCOMM paper. I was a bit surprised to (apparently) see HOL blocking mentioned as a major issue, as that's one of the things QUIC aims to be better at than TCP. It's a bit difficult to understand from the slides, but it seems like you're sending packets for a single stream (Stream ID 1 in the diagrams) on both the slow and fast path, which would indeed induce HOL blocking. Consequently, I was wondering what the practical reasons are for you to multiplex packets for a single stream over multiple paths, as opposed to for example attaching a single stream to a single path (say: high priority streams use the fast path for all their packets). I see this mentioned a bit in the draft under "packet scheduling", where it talks about switching paths once the cwnd is full for one. That indeed leads to the behaviour seen in the slides, but that's my question: why would you take those approaches then? Are there so many cases where the additional "bandwidth" from using multiple path's cwnd for a single stream outweigh the downsides of HOL blocking? Relatedly: what are the packet loss rates you've observed on real networks? Have you experimented with e.g., tying streams to paths more closely? Does that work better or worse? Why? I'm mainly wondering how these tradeoffs evolve depending on the type of paths available and if it's possible to make a model to drive this logic. I assume there is much existing work on this for MPTCP, but I also assume some of that changes due to QUIC's independent streams / stream prioritization flexibility. Thank you in advance and with best regards, Robin On Sun, 11 Jul 2021 at 20:48, Yanmei Liu <miaoji.lym= 40alibaba-inc.com@dmarc.ietf.org> wrote: > Hi everyone, > > We have finished some experiments about deploying multi-path quic > extension(https://datatracker.ietf.org/doc/draft-liu-multipath-quic/) in > Alibaba Taobao short-form video streaming, and the experiment results are > concluded in the slides (attached file). > If anyone is interested in the experimental details about multi-path quic, > please let us know. > All the feedbacks and suggestions are appreciated! > > Best regards, > Yanmei > -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media *Cellphone *+32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
- Multi-path QUIC Extension Experiments Yanmei Liu
- Re: Multi-path QUIC Extension Experiments Robin MARX
- Re: Re: Multi-path QUIC Extension Experiments Ma, Yunfei
- Re: Multi-path QUIC Extension Experiments Mirja Kuehlewind
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Charles 'Buck' Krasic
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Multi-path QUIC Extension Experiments Alexis Norech
- Re: Multi-path QUIC Extension Experiments Charles 'Buck' Krasic
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Lucas Pardue
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Lucas Pardue
- Re: Multi-path QUIC Extension Experiments Lars Eggert
- Re: Multi-path QUIC Extension Experiments Robin MARX
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Behcet Sarikaya
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Ian Swett
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Spencer Dawkins at IETF
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Spencer Dawkins at IETF
- Re: Multi-path QUIC Extension Experiments Yunfei Ma