Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Tue, 09 June 2020 19:45 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1A93A0D40 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 12:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=litespeedtech-com.20150623.gappssmtp.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 blCI3UvDyf7d for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jun 2020 12:45:14 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 DB9D03A0D3D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jun 2020 12:45:12 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jik8R-0000kr-Bm for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jun 2020 19:42:11 +0000
Resent-Date: Tue, 09 Jun 2020 19:42:11 +0000
Resent-Message-Id: <E1jik8R-0000kr-Bm@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <dtikhonov@litespeedtech.com>) id 1jik8Q-0000k1-Af for ietf-http-wg@listhub.w3.org; Tue, 09 Jun 2020 19:42:10 +0000
Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <dtikhonov@litespeedtech.com>) id 1jik8O-0000tZ-Kl for ietf-http-wg@w3.org; Tue, 09 Jun 2020 19:42:10 +0000
Received: by mail-qv1-xf35.google.com with SMTP id ec10so10698000qvb.5 for <ietf-http-wg@w3.org>; Tue, 09 Jun 2020 12:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=7rlGRg0yXZ5HVZ1oBUh3WTQ+jI2WB41BXJ7X8nK7SAY=; b=pulz1jysd449rwLYm3RVCTZtDocztzL1zszABqVr5ubyOOeM872CpF/dzV9XaeBeq0 MDCmBEVm4GyskkCEcSjEq0ibAEPvw7lFVt/rJ511yHqIJctAF59pUZSQeaXF2+zAUeGD l/5y/x7I2t1/mFCOi8Ghf2djKPILB49RX9L7MsX3khgUHqdZbv8BQc+gzJ12h2Je6R/b bqwAoYrneO50fe6qh22mMmj9aaLrILOeT2kuXTpkSDalTZeFS5vYxMzA3/SbNJmnPUcJ 3J7nl/cpWju8pH+xDtlaMf9xMrPi5gbRUzzkRSlMRLhNCBlg3Kp+d3GoWDWk9y2mmLo4 2tVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=7rlGRg0yXZ5HVZ1oBUh3WTQ+jI2WB41BXJ7X8nK7SAY=; b=sQMAnjov9Q//KHBYnNNt/J00wVbYt/QsK3n/QcdlFjwWg/soX0/zVF2iMA3zUU6Aqd TbNyJZ8a5RLQmV/xSIdyCZAiqWKR7b61hs/qj1YziCfXKHr/hO23QSvYkwA1D06oBurP sA7IOs/7d5q+33D9rJb4PiAQ+Q0hR9wqDlNYopZ4u3aKx1E0Fb7ChJb/aZjbJBgVxJ+i sYiJrzp/H7B0M1gvbG/7s/t3QBVVq0Zbi1awUbNBXir7O1yNa3BogeFjJE/wzkmi1u8i cDiK9SPn9Cz8UEs/9a6R1eEcQ3gu76qCBSMSPz6/lan4iAZBcwPHrRQ/rqGhqngM4uRO 2aYw==
X-Gm-Message-State: AOAM5320u9tweGJfW0Vm9sxBkL3RLfeFaKMUjDxFmEgNPZYoGqgKJdlB aHZKw5DP1ZnQsZi/EhGD32LN1A==
X-Google-Smtp-Source: ABdhPJzKD43x6UoBHs+IGukZ1nPMozt6P+vvNnA1R05PYn3PwAHlZqcsGHhPUf2/ECVqHE8fkGrDyg==
X-Received: by 2002:ad4:4a6e:: with SMTP id cn14mr5525631qvb.79.1591731717386; Tue, 09 Jun 2020 12:41:57 -0700 (PDT)
Received: from lubuntu (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id x43sm11339090qtk.70.2020.06.09.12.41.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 12:41:56 -0700 (PDT)
Date: Tue, 9 Jun 2020 15:41:46 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Bence =?iso-8859-1?Q?B=E9ky?= <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>
Message-ID: <20200609194145.GA26778@lubuntu>
Mail-Followup-To: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Bence =?iso-8859-1?Q?B=E9ky?= <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com> <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com> <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com> <CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com> <20200609144428.GC22180@lubuntu> <CALGR9oaXVvAEOu57qrVdyGkjRsE_MDOa_cjFbecZFfWV1x8uVg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALGR9oaXVvAEOu57qrVdyGkjRsE_MDOa_cjFbecZFfWV1x8uVg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=2607:f8b0:4864:20::f35; envelope-from=dtikhonov@litespeedtech.com; helo=mail-qv1-xf35.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jik8O-0000tZ-Kl ece0161a1b36bb291321c717da947b61
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)
Archived-At: <https://www.w3.org/mid/20200609194145.GA26778@lubuntu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37742
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, Jun 09, 2020 at 08:22:10PM +0100, Lucas Pardue wrote:
> On Tue, Jun 9, 2020 at 3:44 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
> wrote:
> >
> > I don't think we can judge either way.  If Alice implements QPACK and
> > Bob implement reprioritization, results will vary based on their level
> > of competence.  The degree of burden will also vary for each
> > particular implementation.
> 
> I agree that, all things considered, QPACK and prioritization are
> dissimilar. However, this thread is specifically exploring the mechanics of
> the reprioritization mechanism, which requires a signal received on one
> stream (the control stream) to affect the send behaviour on another. There
> is always a possibility of a race here. My conjecture is that the
> priorities race ends up being is similar to QPACK'S (i.e. handling blocked
> streams). And therefore if Alice implements QPACK dynamic support
> competently, then implementing reprioritization is no more difficult.

My point was that Alice may have no problem implementing repriotization,
but Bob very well might!  That is to say, there may be more than one
person working on an HTTP/3 stack.  After Bob gives up after three
months leaving reprioritization a steaming pile of crap, Alice (who's
grown to hate that fool) inherits Bob's code, but may not be able to
make a good implementation given tight deadlines.  Alice gets blamed;
Bob gets promoted.  The story gets sadder and sadder in my mind, so
I better stop.

> >   Speaking for lsquic, reprioritization
> > had to [1] touch more code and was much more tightly coupled than
> > QPACK; on the other had, QPACK encoder logic was a lot more code.
> >
> 
> Thanks for sharing your experiences. If we take the scheduling aspects out
> of consideration, the old HTTP/3 priority tree (+ placeholders etc) scheme
> signals were pretty tough to implement.

They were... that made it difficult to part with my implementation

> I suspect that extensible
> priorities' reprioritization would be relatively more simple. But it would
> be interesting to hear from someone that implemented the old scheme
> compared with the new one.

I think so as well.  I will resurrect this thread once we have
reprioritization working and share my thoughts.

  - Dmitri.