Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 28 July 2021 23:53 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 C31D13A0C18; Wed, 28 Jul 2021 16:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 S2kciV89m7cm; Wed, 28 Jul 2021 16:53:30 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 94E633A0C0C; Wed, 28 Jul 2021 16:53:29 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id t26so1792415uao.12; Wed, 28 Jul 2021 16:53:29 -0700 (PDT)
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=uycKlBqPPL1IN1Euz+7QfO4LRy54+T4SYmxA3Yq6oSw=; b=mVNK9IdvCaSIk3f37FXurbLoLBR2P5qkyQrV3IljKCCnXnGzUJXbK/dey/Y8XQFS7u QgaAP2Y+XZa/7NiIC+Fxgmc3ysA9pDdUoxUB9iNRj+yrvXUrmZa9y+/RRBJI4TaOLKB8 qQogoZp/KiBNvrhX5y5WX+8Xp63GMZHI8TjkE8Q+dQnQ+pUdh6qvOuChnoLWtZ/Dgytl eq5Rfg0n14kockqm8mdPBOrW1Di9CAXA1PYwvP/bm2dxa7Kg5FJHfANhVkSi/dQqSyAj 9A5StmYBlqIwT4wEt6zYWeICZARHyoV83E7Rqr+TOA4ohOuCxeOFpc5oIG8BFpJd5jKt AD5A==
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=uycKlBqPPL1IN1Euz+7QfO4LRy54+T4SYmxA3Yq6oSw=; b=qTgn6BhOzwUEm/5ondajXZYfjmotKPDM8o9nRPj6vTbdJap1+1jWH7E1pCfzjcgtU4 s8lKkXgeC1fJf6n0sP22fULq4nB4knco5mckAeOqbvcxSom3B2jQSquqz4xaFXfq+uJM jgHaCS4D5Eyevgczx16nljQmg+/4vAdiuAHuDnQRzoEuOqerR8F8eD0+OloXVqATf6Mp r7jlI/heURwS1PX/xwRu/UlPCVlG85j8Clq/IplWU3JtbN3HLpXTFPt9kzSb1NI8cEbo jU5VUq5uCmDw1FVuFE9jVn78Za25XiGBN7wv4hbb+oa2VvqxNhBy+KtzmqapAS3AffpW LxKQ==
X-Gm-Message-State: AOAM532QFl2ggeWHKdoNXoYg2IP2pnOweC4rhp/U6g+6o4E4s/ScKClt dGbYQxlD/Gimp6B8KrBk242LQ9xqfG+xqAlrloA=
X-Google-Smtp-Source: ABdhPJz41E1mz27SvvulFQBavjtWgZtcuIBeJHGr73Vm/RNcoDgM2mdSqeQGL7tnaiMDihw+hxIyAirSuEByb/V1A7I=
X-Received: by 2002:ab0:7299:: with SMTP id w25mr2559238uao.45.1627516407667; Wed, 28 Jul 2021 16:53:27 -0700 (PDT)
MIME-Version: 1.0
References: <7C8E8AF7-02FA-4AD5-9A53-3A7539758C55@fb.com> <MW3PR11MB4700AAF6E8BB1FE1275876A0E1EA9@MW3PR11MB4700.namprd11.prod.outlook.com> <CAKcm_gOKv+pOmjaEsP1G_MkpKV_PzRMeutBjH+0kw4omi7F74w@mail.gmail.com> <MW3PR11MB4700445490984762C07FEAA6E1EA9@MW3PR11MB4700.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4700445490984762C07FEAA6E1EA9@MW3PR11MB4700.namprd11.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 28 Jul 2021 18:53:01 -0500
Message-ID: <CAKKJt-erv-5waYiganL60eSO10v=Mok35ugzQPQ1Ya_E5K3KQQ@mail.gmail.com>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC
To: "Das, Dibakar" <dibakar.das@intel.com>
Cc: Ian Swett <ianswett@google.com>, Alan Frindell <afrind=40fb.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>, "mops@ietf.org" <mops@ietf.org>, Kirill Pugin <ikir@fb.com>, MORAND Lionel IMT/OLN <lionel.morand@orange.com>, tsvwg-chairs <tsvwg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000585f5605c837b1d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bbUH4_XMV0g0R34jJXNVwGbmyFk>
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, 28 Jul 2021 23:53:35 -0000

Hi, Dibakar,

I apologize in advance if this is not the right venue to ask questions.


This is only my opinion, but this is a fine venue to ask questions. But it
may not be a good venue to resolve issues. Please take what follows as
suggestions.

There are people who understand some of the ins and outs of (for instance)
5G RAN, but honestly, there aren't a lot of them, so I'd start with 3GPP.

If this was a concern I had, the first place I'd stop is with Lionel Morand
(lionel.morand@orange.com) the 3GPP liaison to the IETF, to share this
concern. Lionel tends to be the person who sets agendas for the 3GPP-IETF
coordination team.

IETF participants are likely to say "if it hurts (performance) when you do
that, you probably should stop doing that". In my opinion, that's because
those participants don't want to special-case their protocols (especially
transport-level protocols) to deal with L2 characteristics that won't be
true for all underlying networking technologies.

The PILC working group, concluded about 20 years ago, put together a
nuanced discussion about L2 retransmissions in
https://datatracker.ietf.org/doc/html/rfc3819#section-8.1. If anyone in the
IETF thought that reasoning needed to be updated, I'd start with the TSVWG
chairs, at tsvwg-chairs@ietf.org - I believe this would be in scope for
them, and Gorry Fairhurst, one of the RFC 3819 co-authors, is also a TSVWG
chair, so that would jumpstart things.

The current TSV ADs might have opinions about what should happen, but the
TSVWG co-chairs can involve them if they need to be involved.

I've taken the liberty of copying Lionel and the TSVWG chairs, so if you do
reach out to them, they'll know what you're talking about.

I hope this is helpful, and good luck on helping IETF and 3GPP Do The Right
Thing. I know that's important.

If I can explain any of this further, please email me privately, just to
minimize the hit on people's inboxes.

Best,

Spencer (full disclosure: I co-chaired PILC with Aaron Falk)

On Wed, Jul 28, 2021 at 3:17 PM Das, Dibakar <dibakar.das@intel.com> wrote:

> Hi Ian,
>
>
>
> Thanks for the response.
>
>
>
> I think having some signaling visible to the network layer could be useful
> for the transmitter in the wireless link (say, an AP) as it can take this
> information into account while preparing the packets. It can even be used
> in current WiFi (i.e., with in-order delivery) to optimize its scheduling
> for that stream for example, it can send a Ctrl frame soon to clear holes
> in the reorder buffer at the recipient.
>
>
>
> Regards,
>
> Dibakar
>
>
>
>
>
> *From:* Ian Swett <ianswett@google.com>
> *Sent:* Wednesday, July 28, 2021 12:42 PM
> *To:* Das, Dibakar <dibakar.das@intel.com>
> *Cc:* Alan Frindell <afrind=40fb.com@dmarc.ietf.org>; quic@ietf.org;
> mops@ietf.org; Kirill Pugin <ikir@fb.com>
> *Subject:* Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30
> 18:00 UTC
>
>
>
> Hi,
>
>
>
> I can't answer for Alan, but my belief is yes.  Client wifi stacks
> sometimes also do some reordering(and introduce the corresponding latency),
> so if we could design an indication that in-order delivery has no value, it
> could be fairly widely applicable.
>
>
>
> That being said, I don't know what the right mechanism is?  Would we need
> something visible to a network or can we get away with a socket option that
> propagates to the local 5G network or Wifi firmware when possible?
>
>
>
> Ian
>
>
>
> On Wed, Jul 28, 2021 at 3:15 PM Das, Dibakar <dibakar.das@intel.com>
> wrote:
>
> Hi Kirill, Alan,
>
>
>
> I could not attend the call this week and wont be able to attend this side
> meeting either.
>
>
>
> But I had a general question about the performance of all such QUIC based
> protocols over wireless. Typically, the 5G and WiFI MAC layers deliver
> frames in-order which sort of recreates the HOL blocking problem at lower
> layers. I would expect this to in turn prevent the QUIC protocol to achieve
> its full performance gains at least in some congested network scenarios.
> Considering that in-order delivery is made optional in 5G PDCP, I was
> wondering if there could be a value to have some signaling defined in the
> QUIC (or RUSH ?) protocol that would allow lower layers to make better
> decision about whether to enable/disable in-order delivery for certain
> streams.
>
>
>
> I apologize in advance if this is not the right venue to ask questions.
>
>
>
> Regards,
>
> Dibakar
>
>
>
>
>
>
>
> *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of *Alan Frindell
> *Sent:* Wednesday, July 28, 2021 8:42 AM
> *To:* avt@ietf.org; wish@ietf.org; QUIC WG <quic@ietf.org>; mops@ietf.org
> *Cc:* Kirill Pugin <ikir@fb.com>
> *Subject:* Reminder: Video Ingest over QUIC Side Meeting Friday 7/30
> 18:00 UTC
>
>
>
> Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC / 11 Pacific
>
>
>
> Link to draft agenda and video conference details:
> https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md
>
>
>
> -Alan
>
> --
> Mops mailing list
> Mops@ietf.org
> https://www.ietf.org/mailman/listinfo/mops
>