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

Dmitri Tikhonov <> Tue, 09 June 2020 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F1A93A0D40 for <>; Tue, 9 Jun 2020 12:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id blCI3UvDyf7d for <>; Tue, 9 Jun 2020 12:45:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB9D03A0D3D for <>; Tue, 9 Jun 2020 12:45:12 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jik8R-0000kr-Bm for; Tue, 09 Jun 2020 19:42:11 +0000
Resent-Date: Tue, 09 Jun 2020 19:42:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jik8Q-0000k1-Af for; Tue, 09 Jun 2020 19:42:10 +0000
Received: from ([2607:f8b0:4864:20::f35]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jik8O-0000tZ-Kl for; Tue, 09 Jun 2020 19:42:10 +0000
Received: by with SMTP id ec10so10698000qvb.5 for <>; Tue, 09 Jun 2020 12:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ( []) by with ESMTPSA id x43sm11339090qtk.70.2020. (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 <>
To: Lucas Pardue <>
Cc: HTTP Working Group <>, Bence =?iso-8859-1?Q?B=E9ky?= <>, Kazuho Oku <>
Message-ID: <20200609194145.GA26778@lubuntu>
Mail-Followup-To: Lucas Pardue <>, HTTP Working Group <>, Bence =?iso-8859-1?Q?B=E9ky?= <>, Kazuho Oku <>
References: <> <> <> <> <> <20200609144428.GC22180@lubuntu> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=2607:f8b0:4864:20::f35;;
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: 1jik8O-0000tZ-Kl ece0161a1b36bb291321c717da947b61
Subject: Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)
Archived-At: <>
X-Mailing-List: <> archive/latest/37742
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 <>
> 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.