Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC
Roland Zink <roland@zinks.de> Thu, 29 July 2021 09:33 UTC
Return-Path: <roland@zinks.de>
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 D7F9F3A1B1C for <quic@ietfa.amsl.com>; Thu, 29 Jul 2021 02:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=zinks.de
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 GwjQInSuRFWL for <quic@ietfa.amsl.com>; Thu, 29 Jul 2021 02:33:50 -0700 (PDT)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AD53A1B1A for <quic@ietf.org>; Thu, 29 Jul 2021 02:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627551226; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject:Cc:Date:From: Subject:Sender; bh=dZ5xH6DJ5EMBXdcjbTyS+LuSYLDW+jDhfYLMjTm1oM8=; b=G7a0vIP0k5kN1TWulQf+KgVL743/0XYpeM7XFt7ASzkXRLa7QcaQ31Bj5jGUPrThA+ Fh1Hd+fC3J6WRMvvsPnd7z+G4qjHhgrDlbhWINsFXBSZ1xv2YMK9UO3Ze0auDfIqYctS thDsYQxbBjUaNJHbnyIQTPRiFkwVlUdXkNFqWS0SDlk7QHDe6k+LjlG3KSgSHLTJj8pQ lzHu7dtlidbNM69uLv3rk9yimf1JkVoEZ8wjDVqwPPSATbjfDhq/ZDUDg57RV5mNFkUG WzZvrjOg65re8kIPc+gqkqjo/e+mjLy/AH88fng64LJ8jhTTUHfjixvmR3ZTLE2dSFoO bSPg==
Authentication-Results: strato.com; dkim=none
X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr4qxFkqYR5Yz/K5GkLh+dV4vjFRpfy4IUcDCMZ"
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2003:f4:7703:5300:8055:a9d:6e8f:2599] by smtp.strato.de (RZmta 47.28.1 AUTH) with ESMTPSA id V07846x6T9XkuOd (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for <quic@ietf.org>; Thu, 29 Jul 2021 11:33:46 +0200 (CEST)
Subject: Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC
To: quic@ietf.org
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>
From: Roland Zink <roland@zinks.de>
Message-ID: <ba86a528-79f1-56a3-7dbd-4913a69a802d@zinks.de>
Date: Thu, 29 Jul 2021 11:33:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <CAPDSy+7aVAP8yw=K_SMrRDYJ_SVj0ixNpsGDhhDUhXOKU-HWWg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4A9BD24FCC4A510A285C5139"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/uraVxajjS0wTgEtguBwP6mJsL3s>
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, 29 Jul 2021 09:33:56 -0000
Hi David, In mobile networks the L2 transport block vary in size and can contain only a small fraction of an IP packet or several 1500 bytes packets. When filling the transport block you may have the chance to pack in the beginning of the next arrived packet or a complete but smaller IP packet. When the transport block can't be successfully transferred but the next one is then this may create a sort of HoL blocking, e.g. the remaining of the incomplete IP packet can't be forwarded until the transport block is retransmitted. Regards, Roland Am 7/28/2021 um 11:15 PM schrieb David Schinazi: > Why would we need a signal here? This applies to all traffic, be it > TCP QUIC or anything else. Firmwares introducing latency to reorder > packets was a reaction to bad implementations of TCP from a long time > ago that have been fixed in systems that care about performance. In > today's world, L2 is better off delivering any and all packets in the > order they arrive instead of introducing buffer bloat. > > David > > On Wed, Jul 28, 2021 at 1:24 PM Roberto Peon > <fenix=40fb.com@dmarc.ietf.org <mailto:40fb.com@dmarc.ietf.org>> wrote: > > The ideal would be to have public bits that were intended to be > interpreted by (as you say, visible to) those layers so any L2 > could adapted appropriately without reinventing the wheel. > It isn’t just the local radio firmware that one needs to worry > about—it is also the basestation(s) that may be “helping”. > > Separately, but also important, is being able to get signals from > the application about what tradeoffs should be at the network. I > believe that this dovetails into many of the multipath issues, btw. > > A couple potentially interesting params are: > > A bit to say please don’t HoL block > Some kind of mechanism(s) to bound retries (e.g. “don’t retry > bit”, but that is obviously not as expressive as throw out packet > older than X microseconds) > > > -=R > > *From: *QUIC <quic-bounces@ietf.org > <mailto:quic-bounces@ietf.org>> on behalf of Ian Swett > <ianswett=40google.com@dmarc.ietf.org > <mailto:40google.com@dmarc.ietf.org>> > *Date: *Wednesday, July 28, 2021 at 12:42 PM > *To: *"Das, Dibakar" <dibakar.das@intel.com > <mailto:dibakar.das@intel.com>> > *Cc: *Alan Frindell <afrind=40fb.com@dmarc.ietf.org > <mailto:40fb.com@dmarc.ietf.org>>, "quic@ietf.org > <mailto:quic@ietf.org>" <quic@ietf.org <mailto:quic@ietf.org>>, > "mops@ietf.org <mailto:mops@ietf.org>" <mops@ietf.org > <mailto:mops@ietf.org>>, Kirill Pugin <ikir@fb.com > <mailto: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 <mailto: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 > <mailto:quic-bounces@ietf.org>> *On Behalf Of *Alan Frindell > *Sent:* Wednesday, July 28, 2021 8:42 AM > *To:* avt@ietf.org <mailto:avt@ietf.org>; wish@ietf.org > <mailto:wish@ietf.org>; QUIC WG <quic@ietf.org > <mailto:quic@ietf.org>>; mops@ietf.org <mailto:mops@ietf.org> > *Cc:* Kirill Pugin <ikir@fb.com <mailto: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 > <https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md> > > -Alan >
- Reminder: Video Ingest over QUIC Side Meeting Fri… Alan Frindell
- RE: Reminder: Video Ingest over QUIC Side Meeting… Das, Dibakar
- Re: Reminder: Video Ingest over QUIC Side Meeting… Ian Swett
- RE: Reminder: Video Ingest over QUIC Side Meeting… Das, Dibakar
- Re: Reminder: Video Ingest over QUIC Side Meeting… Roberto Peon
- Re: Reminder: Video Ingest over QUIC Side Meeting… David Schinazi
- Re: Reminder: Video Ingest over QUIC Side Meeting… Roberto Peon
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Holland, Jake
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Spencer Dawkins at IETF
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Matt Joras
- RE: [Mops] Reminder: Video Ingest over QUIC Side … Anna Brunström
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Holland, Jake
- RE: [Mops] Reminder: Video Ingest over QUIC Side … Das, Dibakar
- Re: Reminder: Video Ingest over QUIC Side Meeting… Roland Zink
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Zaheduzzaman Sarker
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Spencer Dawkins at IETF
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Sergio Garcia Murillo
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Zaheduzzaman Sarker
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Ian Swett
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Holland, Jake
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Ali C. Begen
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Ian Swett
- Re: [Mops] Reminder: Video Ingest over QUIC Side … Spencer Dawkins at IETF
- Minutes from Video Ingest over QUIC side meeting Alan Frindell