Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-httpbis-priority-11: (with COMMENT)

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 14 Dec 2021 14:52:47 -0800

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-httpbis-priority-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for working on the HTTP priority. I hope to see this specification gets
deployed and we learn how to efficiently use priorities more.

I have two comments that might have been already thought about -

  - Section 12: I was wondering how much it would be different to have same
  considerations for TCP as we have for QUIC - specially for "Endpoints SHOULD
  prioritize retransmission of data over sending new data, unless priorities
  specified by the application indicate otherwise". Could this be a very
  transport agnostic behavior this specification can define?

  - Section 13.1 : it says  -

      "if a server knows the intermediary is coalescing requests, then it could
      avoid serving the responses in their entirety and instead distribute
      bandwidth (for example, in a round-robin manner)"

    It would be great if we can mention any known or standard way for the
    servers to know about the intermediary. If there is non or if the is not
    deterministic way for the server to learn about how the intermediary works
    then I would argue that Section 13.1 is an unnecessary details.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 Dec 2021 23:41:41 +0000

Hi Zahed,

Thank you for your review. Responses to your comments are in-line:

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/

I think there's a few factors that make considerations for TCP harder to
put down in a document like this. First is that we see a lot of HTTPS usage
today, whereby the application protocol of HTTP is abstracted away from the
transport by a TLS record layer. Second is that many APIs for TCP tend to
abstract a lot of detail away from applications - once the data is written
via a socket call, it can behard to know exactly when and what was
transmitted, and when or what was lost and needs retransmission. Third is
the relationship between HTTP/2 stream concurrency and the weak
coordination to layers underneath it; TCP HoL blocking exists and causes
problems because streams are not independent at the transport layer -
prioritizing retransmissions (if it's even possible in the implementation)
probably doesn't help to address that.

In contrast, QUIC's streams, packet protection, and data (not packet)
retransmission allows it to be a lot more adaptive to dynamic conditions.
QUIC streams are truly independent and RFC 9000 notes the benefits of
prioritization and reprioritization itself. We simply build on that. I'm
not aware of an IETF document that similarly documents TCP retransmission
priority but I'm happy to be told otherwise. But even then, I think the
above factors make that hard to speak to.

Since we do mention TCP in Section 12 but don't say anything further, I'm
wondering if it might help to add a small editorial note that simply
acknowledges that TCP retransmission is hard and no considerations are
presented. WDYT?

>     then I would argue that Section 13.1 is an unnecessary details.

Paragraph 4 of Section 13.1 contains mention about detecting the presence
of the intermediary based on Forward (X-Forwarded-For) and Via. Other
headers (some non-standard) can be similarly used. But more often than not
these days, such intermediaries are present due to a business relationship
between the intermediary and the origin server - for example an L7 load
balancer or a CDN. In such cases there is out-of-band or assumed knowledge
about the conditions and behavior. The HTTP WG is continuing to produce
work like draft-ietf-httpbis-targeted-cache-control that helps to shift
some of this knowledge to more common and interoperable formats. I could
speculate that other drafts might address other aspects of the relationship
like we are talking about here. Speculation is dangerous of course :)

I do think there is value in keeping Section 13.1. Even if we can't
enumerate all the exact ways for an origin to detect an intermediary or its
behavior. Removing it challenges the consensus of the WG.

Cheers,
Lucas