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

Hi Zahed,

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

On Tue, Dec 14, 2021 at 10:52 PM Zaheduzzaman Sarker via Datatracker <
noreply@ietf.org> wrote:

> 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?
>

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?


>
>   - 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.
>

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