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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 30 July 2021 14:07 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 673AA3A2B61; Fri, 30 Jul 2021 07:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.904
X-Spam-Level: **
X-Spam-Status: No, score=2.904 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y0XSWmA9J60K; Fri, 30 Jul 2021 07:07:21 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 CD9D83A22B7; Fri, 30 Jul 2021 07:07:20 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id x66so2981973vsb.1; Fri, 30 Jul 2021 07:07:20 -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=pwRpArtpdIV965RUdbDgpQQQfwET3xWn51SJH6EgDjw=; b=t4Hx8BD6A+IOKMQNkMUdzqw1k33Djz8rMh6DXPrWfpk9bJgKyEHh2M68JrXYTeY3WP hL06VNjrN/hh8ZzobusuStwUcPIapvEyzxaPam59kzbaCeaS2dHgeTJszGUuWfVvHUCq vJ/se4puX1HIW8iblUyiSG0RsFzmmiM8a0d8IXkHLZ/htS6ZcRBMLD0YXWbMhUFQFN9A Wbvb5dk5U0doH/3m1APnHbJFj4tb90SlJcRcqY5yrBwdS+jjXFzyYGMFmRhEgOKkWevp ySICZkfcqkeNo3fX3ICx0PAGOVm7XpR2cpodD4UrObgV55tS5WIp7DAD1e4HYQxy7Jv4 NMbQ==
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=pwRpArtpdIV965RUdbDgpQQQfwET3xWn51SJH6EgDjw=; b=qbtZXO2sFBTEcJi7Dw0HZa1UtsK4ofuhyuerHlADsj1XVetJrItcdOfwr9Kwe2mfeb Vvuz7BEx1RSbT06GcOdhgc4sXg5TaJklJ8B7q/vF8ITnpmTptRKs+Q/mPp+dP2uwqDws 1h5kh608Er/ecydpfq2/osmV/5FL31v2ItDev6YeRVeHzAAwCvgFxapJnJ2d1jPYUQQf f8WQFZspf0MVD+AYYS4YOxemilcOyVKOiAGG3OZtjpCdlGaz5mgrS+u4rdxEP+V8HLI7 EIhj3XLBjmMumkMrZzDqK1Ah8YgkLHoSGkz9+T9+lKztIe14c6OcCl1EBvqSjYOL1GDP mBrg==
X-Gm-Message-State: AOAM533JvV2w/Gh0j591uuzvnpVdKgDooYGZD0A4ypaqBnkrsxkjtDVQ Ruc6/IYTlpdpNq9A31OAgmUtKqMu21j0bl87Pgo=
X-Google-Smtp-Source: ABdhPJxQvezgp1Ts71SV6q4ZOfbFHMHQgCV1LdgzLXtULZzBBj7Rpa/Yz9zeppvw7lihq44o7M+jViJSmfvLVJDPjtY=
X-Received: by 2002:a67:d71d:: with SMTP id p29mr1665784vsj.26.1627654039425; Fri, 30 Jul 2021 07:07:19 -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> <FB63F7E1-6827-4B97-B3D2-5AB5E3C5487E@fb.com> <CAPDSy+7aVAP8yw=K_SMrRDYJ_SVj0ixNpsGDhhDUhXOKU-HWWg@mail.gmail.com> <85EBC68C-0B48-4A45-8F72-7A3C82D28812@akamai.com> <CADdTf+jrVu1YE03+Y0-NR+v+SiYDv7LqukbMA0Zc6n9rj1X3qQ@mail.gmail.com> <863528193a4945c48498d0b5f01c4dd6@kau.se> <825FDDDF-E12A-4BFC-A489-3982E0DD6BBC@akamai.com> <CA+ag07YAqRAGV2+r4k9CNaUm3KE2ebU0o3cAZtwcubW8CbmAbA@mail.gmail.com> <AB7B1FF5-BD3B-4DA0-B438-699C87ED2B5A@ericsson.com> <CAKcm_gMOFG_pquhCtSsMtMOZ6Tjb5Rimr0SvwK9Umw5sFqm-6w@mail.gmail.com>
In-Reply-To: <CAKcm_gMOFG_pquhCtSsMtMOZ6Tjb5Rimr0SvwK9Umw5sFqm-6w@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 30 Jul 2021 09:06:52 -0500
Message-ID: <CAKKJt-dXwm=mgmM=Px3NupAcaxa0GHYdVzzduXfmodO9VjL4MQ@mail.gmail.com>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: "mops@ietf.org" <mops@ietf.org>, "Das, Dibakar" <dibakar.das@intel.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d6579405c857bc94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DcGoGfsvY0Ukdp3C6Je2JS8stBc>
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: Fri, 30 Jul 2021 14:07:26 -0000

Trimming down to just the mailing lists, because I was getting rejection
messages from AVTCORE because of too many addresses in To/CC ...

On Thu, Jul 29, 2021 at 9:43 PM Ian Swett <ianswett=
40google.com@dmarc.ietf.org> wrote:

> TLDR: Ideally, handling reordering on the receiving host will
> reduce user latency and be cheaper for everyone.
>
> Changing the TCP ecosystem is slow, so I can't advise immediately doing
> this for TCP traffic, but doing this now for QUIC(and maybe documenting it
> in Manageability?) seems viable.  If we wait longer, the ecosystem will be
> ossified.  I'm not sure anyone is willing to introduce intentional
> reordering to GREASE the loss detection system and ensure implementations
> adapt, but I'll discuss if that's something we would do for some traffic
> when sending multi-packet bursts.
>
> I believe the vast majority of QUIC applications would benefit from
> increased reordering if it reduced latency and buffering.  In TCP, you can
> detect reordering from the sequence number.  But for QUIC, the metadata is
> encrypted, so a given network can only attempt to reduce reordering in a
> much narrower context, which is much less useful.  Add into that the fact
> you don't know the application, and the benefits of delaying packets within
> the network/path become even more difficult to reason about.
>

I utterly and completely agree with what Ian says here (and echo Jake's
subsequent +1), and I note that although we seem to be keeping "multipath
QUIC" on the QUIC back-burner, applications that manage multiple paths at
the application level, especially if those paths are largely divergent,
make those benefits even further more difficult to reason about.

So maybe "bringing on the grease for reordering" would be a great thing to
do, before the network elements start trying to be helpful.

Best,

Spencer


> To frame this in statistical terms, the sum of multiple normal
> distributions is a normal distribution with the sum of the means and a sum
> of the variances(
> https://en.wikipedia.org/wiki/Sum_of_normally_distributed_random_variables)
> Since the standard deviation is the square root of the variance, the
> standard deviation is dominated by the largest source of variation, and if
> each link introduces some variance, it's really only the one that
> introduces the most variation that matters.  Given no link knows whether
> it's the dominant source of variation on the path, I'd suggest every link
> pass along packets as soon as possible.  Obviously, link-layer error
> correction and other approaches which increase reliability without
> introducing delay are still welcome and valuable.
>
> Thanks, Ian
>
>
>
> On Thu, Jul 29, 2021 at 2:10 PM Zaheduzzaman Sarker <
> zaheduzzaman.sarker@ericsson.com> wrote:
>
>> I would say this is not specific to media over QUIC. However, a potential
>> solution to this could boost the deployment of potential radio technologies
>> ( for example - Unacknowledgement Mode (UM) of RLC in cellular networks)
>> which might actually help low latency media usecases.
>>
>>
>>
>> BR
>>
>> Zahed
>>
>>
>>
>> On 2021-07-29, 22:35, "QUIC on behalf of Sergio Garcia Murillo" <
>> quic-bounces@ietf.org on behalf of sergio.garcia.murillo@gmail.com>
>> wrote:
>>
>>
>>
>> Just for clarification, if this needs to be handled, this should be
>> handled at QUIC level and it is not an specific problem for the Media over
>> QUIC protocol, right?
>>
>>
>>
>> El jue., 29 jul. 2021 18:15, Holland, Jake <jholland=
>> 40akamai.com@dmarc.ietf.org> escribió:
>>
>> Hi Anna,
>>
>>
>>
>> (And replacing Nathalie’s email with the correct one, hopefully)
>>
>>
>>
>> That was not quite my understanding, no.  Sorry if I opened this
>> discussion poorly.  In Nathalie’s initial response, she clarified that it’s
>> configurable, including the option to disable the reordering buffer.
>>
>>
>>
>> However, I understood this as an option available to the service provider
>> operating the MP-DCCP split path proxies that tunnel the carried traffic,
>> not necessarily to the endpoints or the applications having their traffic
>> split.
>>
>>
>>
>> Depending on how it’s deployed, this may or may not be a problem for
>> particular endpoints, but I couldn’t tell if there was an obvious or easy
>> way for an application to select the use case (particularly one that is
>> just trying to use QUIC and transparently getting traffic-splitting
>> delivery) in a way that the operator will understand, so I thought it best
>> to raise the point for discussion.
>>
>>
>>
>> Best,
>>
>> Jakean/listinfo/mops <https://www.ietf.org/mailman/listinfo/mops>
>>
>>