Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

[Kazuho Oku <[e-mail]>]

Hi Martin,

Thank you for your comments. My personal responses inline.

2019年11月21日(木) 8:17 Martin Thomson <[e-mail]>:

> Kazuho,
>
> Thanks for putting this together.  I only looked briefly, but this appears
> to faithfully capture what we discussed.
>
> Why did you choose to express this with a dictionary `u=4, i=?1`** rather
> than a numeric item `4;i=?1`?
>

The primary benefit is to let the server update the "i" (interleaved)
parameter only. Sometimes, only the server knows If the response is
incrementally processible in a meaningful way (e.g., progressive JPEG vs.
baseline JPEG). It is therefore beneficial to let the server specify the
"i" parameter without messing with "u" (urgency).

The other benefit would be that providing room for future extensions to
define new parameters as SH Dictionary members rather than parameters, as
only the former can take be accompanied with a compound value.


>
> Can we look to simplifying this a little more?  I understand that
> reprioritization was identified as being important by the design team, but
> I don't recall seeing ever any evidence to support that view.  Can we split
> that piece out and maybe pursue it separately?
>

There seemed to be certain amount of agreement that three features
(client-driven prioritization, server intervention, reprioritization) was
necessary. That said, I agree that we can cleanly split reprioritization
from the scope of the draft, and at the moment I would not oppose to that
if that is the preference of HTTP WG.


>
> I would prefer to frame the way in which priorities are "merged" (Section
> 6) differently.  I would instead say that the priority information is input
> to prioritization decisions that endpoints/intermediaries/etc.. make.  So I
> would instead say that these entities simply make their own decision about
> the way to incorporate these signals into their decision.  That's probably
> a systemic thing that affects more than Section 6; I see that the draft
> uses "obey" in Section 7.1.1, for example.
>
> There seems - at least to me - to be an assumption on the part of some
> people involved in this that Priority will be interpreted as an
> imperative.  That is, that a client might be able to tell a server to act
> in a particular way and expect to have that instruction complied with.
> Same for servers and proxies.  That might be an appealing, but I can't see
> any way in which we can rely on that.  To the example in the draft, as a
> CDN, I would expect that the server's view carries more weight than the
> client's, but I wouldn't necessarily say that this something as absolute as
> is currently implied.
>

I agree that the priority parameters are merely hints, and that we do not
need to mandate exactly how they would be implemented. Though I think we
need to provide expectations on how H2/H3 terminators are expected to
prioritize is important for other endpoints using the signal.


> ** The draft is unclear as to whether it is `u=4,i=?1` or `u=4;i=?1`,
> which you might want to double-check.
>

The parameters are SH dictionary members. Therefore `,` is the correct
answer.


> On Wed, Nov 20, 2019, at 20:04, Kazuho Oku wrote:
> > Dear working groups members,
> >
> > After the HTTPbis meeting on Monday, the priorities design team as well
> > as others have had discussions, and have converged on a particular
> > design (header-based, as well as allowing intermediaries to send frames
> > to express per-hop priorities).
> >
> > We have submitted a new revision of the I-D that reflects the emerging
> > consensus, that clarifies more about the corner cases and how they
> > should be handled.
> >
> > It can be found at:
> > https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
> > HTML version is:
> >
> https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html
> >
> > We have asked chairs to give us some time in tomorrow's HTTPbis meeting
> > that we can use to provide an update on the status.
> >
> > We are looking forward to hearing your comments either face-to-face, or
> > on the mailing list.
> >
> > Thank you in advance.
> >
> > ---------- Forwarded message ---------
> > From: <[e-mail]>
> > Date: 2019年11月20日(水) 19:53
> > Subject: New Version Notification for
> draft-kazuho-httpbis-priority-04..txt
> > To: Kazuho Oku <[e-mail]>, Lucas Pardue <
> [e-mail]>
> >
> >
> >
> >  A new version of I-D, draft-kazuho-httpbis-priority-04.txt
> >  has been successfully submitted by Kazuho Oku and posted to the
> >  IETF repository.
> >
> >  Name: draft-kazuho-httpbis-priority
> >  Revision: 04
> >  Title: Extensible Prioritization Scheme for HTTP
> >  Document date: 2019-11-20
> >  Group: Individual Submission
> >  Pages: 20
> >  URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-04.txt
> >  Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
> >  Htmlized: https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
> >  Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
> >  Diff:
> https://www.ietf.org/rfcdiff?url2=draft-kazuho-httpbis-priority-04
> >
> >  Abstract:
> >  This document describes a scheme for prioritizing HTTP responses.
> >  This scheme expresses the priority of each HTTP response using
> >  absolute values, rather than as a relative relationship between a
> >  group of HTTP responses.
> >
> >  This document defines the Priority header field for communicating the
> >  initial priority in an HTTP version-independent manner, as well as
> >  HTTP/2 and HTTP/3 frames for reprioritizing the responses. These
> >  share a common format structure that is designed to provide future
> >  extensibility.
> >
> >
> >
> >
> >  Please note that it may take a couple of minutes from the time of
> submission
> >  until the htmlized version and diff are available at tools.ietf.org.
> >
> >  The IETF Secretariat
> >
> >
> >
> > --
> > Kazuho Oku
>
>

-- 
Kazuho Oku