Internet DRAFT - draft-bishop-httpbis-priority-placeholder
draft-bishop-httpbis-priority-placeholder
HTTPbis M. Bishop
Internet-Draft Akamai
Intended status: Standards Track February 6, 2018
Expires: August 10, 2018
Priority Placeholders in HTTP/2
draft-bishop-httpbis-priority-placeholder-01
Abstract
RFC7540 defines HTTP/2, including a method for communicating
priorities. Some implementations have begun using closed streams as
placeholders when constructing their priority tree, but this has
unbounded state commitments and interacts poorly with HTTP/QUIC.
This document proposes an extension to the HTTP/2 priority scheme for
both protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 10, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Bishop Expires August 10, 2018 [Page 1]
Internet-Draft Placeholders in HTTP/2 February 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. The Priority Placeholder Extension to HTTP/2 . . . . . . . . 3
2.1. Priority Placeholder Setting . . . . . . . . . . . . . . 3
2.1.1. Mid-session updates . . . . . . . . . . . . . . . . . 3
2.2. Frame Modifications . . . . . . . . . . . . . . . . . . . 4
2.2.1. Existing Frame Types . . . . . . . . . . . . . . . . 4
2.2.2. PLACEHOLDER_PRIORITY Frame . . . . . . . . . . . . . 4
2.3. Priority Management Logic . . . . . . . . . . . . . . . . 5
3. Incorporating Placeholders in HTTP/QUIC . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. SETTINGS_PLACEHOLDERS Setting . . . . . . . . . . . . . . 7
5.2. PLACEHOLDER_PRIORITY Frame . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Stream Priority is described in [RFC7540], Section 5.3. Priority is
communicated using PRIORITY frames and with reference to other
streams, with stream 0 being the root of the tree. Each stream
depends on one other stream with a particular weight; these weights
represent relative priorities among the multiple children of a
stream.
Unfortunately, the scheme as specified encourages servers to actively
maintain closed streams in the priority tree, since other streams
might reference them later. This produces an unbounded state
commitment on the part of the server if it is to correctly reflect
any possible reference the client might make. While priorities are
only advisory and the server is free to discard as much state as it
needs to, references to streams which are no longer in the server's
state are treated as references to the root of the tree. This can
result in wildly different conceptions of the priority tree between
client and server, a situation which all parties would prefer to
avoid.
Bishop Expires August 10, 2018 [Page 2]
Internet-Draft Placeholders in HTTP/2 February 2018
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. The Priority Placeholder Extension to HTTP/2
This extension consists of an additional setting Section 2.1, changes
to the set of HTTP/2 frames Section 2.2, and modified state
management logic on the server Section 2.3.
2.1. Priority Placeholder Setting
An HTTP/2 peer that supports Priority Placeholders indicates this
using the HTTP/2 "SETTINGS_PLACEHOLDERS" (0xSETTING-TBD) setting.
When a value for the "SETTINGS_PLACEHOLDERS" setting is not set, this
indicates that the peer does not support the extension, and other
protocol elements in this document MUST NOT be used. A client that
supports this extension SHOULD set this value to 0 (0x00).
A server which supports this extension MUST set this value to a non-
zero number indicating the number of placeholders it is willing to
make available to the client, which MUST be at most 2^31-1. Clients
MUST NOT use the protocol elements in this document unless the server
has indicated support by setting a non-zero value.
2.1.1. Mid-session updates
HTTP/2 permits settings to change during the course of a connection.
This setting can be freely increased at any time without consequence,
and servers SHOULD NOT reduce the value during the lifetime of a
connection.
If a client receives a reduction in the number of permitted
placeholders, it MUST assume that all placeholders over the new limit
have been pruned from the tree and SHOULD immediately issue PRIORITY
and PLACEHOLDER_PRIORITY frames as necessary to rebuild the priority
tree as desired. Once the SETTINGS frame has been acknowledged,
servers should treat the excess placeholders as inactive and prune
them following the same logic in Section 2.3.
Bishop Expires August 10, 2018 [Page 3]
Internet-Draft Placeholders in HTTP/2 February 2018
2.2. Frame Modifications
2.2.1. Existing Frame Types
When client and server have opted in to this extension, the HTTP/2
PRIORITY frame and HEADERS frame contain one additional flag:
DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the
value in the Stream Dependency field is a Placeholder ID rather
than a Stream ID.
In HEADERS, this flag MUST NOT be set if the PRIORITY flag is not
set.
2.2.2. PLACEHOLDER_PRIORITY Frame
The PLACEHOLDER_PRIORITY (type=0xFRAME-TBD) frame specifies the
sender-advised priority of a placeholder. It MUST be sent only on
Stream 0. The semantics of the Stream Dependency, Weight, and E flag
are the same as in the HTTP/2 PRIORITY frame.
The flags defined are:
E (0x01): Indicates that the stream dependency is exclusive (see
[RFC7540], Section 5.3).
DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the
value in the Stream Dependency field is a Placeholder ID rather
than a Stream ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Placeholder ID (31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Stream Dependency (31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (8) |
+-+-+-+-+-+-+-+-+
Figure 1: PRIORITY frame payload
The PLACEHOLDER_PRIORITY frame payload has the following fields:
Prioritized Stream: A 31-bit stream identifier for the request
stream whose priority is being updated.
Bishop Expires August 10, 2018 [Page 4]
Internet-Draft Placeholders in HTTP/2 February 2018
Stream Dependency: A 31-bit stream or placeholder identifier for the
request stream that this stream depends on (see [RFC7540],
Section 5.3).
Weight: An unsigned 8-bit integer representing a priority weight for
the stream (see [RFC7540], Section 5.3). Add one to the value to
obtain a weight between 1 and 256.
A PLACEHOLDER_PRIORITY frame MUST have a payload length of nine
octets. A PLACEHOLDER_PRIORITY frame of any other length MUST be
treated as a connection error of type PROTOCOL_ERROR if the sender
has advertised support for this extension, and ignored otherwise.
2.3. Priority Management Logic
This extension provides a mechanism for servers to limit how many
additional IDs which do not refer to an active request will be used
to maintain priority state. Because the server commits to maintain
these inactive IDs, clients can use them with confidence that the
server will not have discarded the state without warning.
In exchange, the server knows it can aggressively prune inactive
regions from the priority tree, because placeholders will be used to
"root" any persistent structure of the tree which the client cares
about retaining. For prioritization purposes, a node in the tree is
considered "inactive" when the corresponding stream has been closed
for at least two round-trip times (using any reasonable estimate
available on the server). This delay helps mitigate race conditions
where the server has pruned a node the client believed was still
active and used as a Stream Dependency.
Specifically, the server MAY at any time:
o Identify and discard branches of the tree containing only inactive
nodes (i.e. a node with only other inactive nodes as descendants,
along with those descendants)
o Identify and condense interior regions of the tree containing only
inactive nodes, allocating weight appropriately
Bishop Expires August 10, 2018 [Page 5]
Internet-Draft Placeholders in HTTP/2 February 2018
x x x
| | |
P P P
/ \ | |
I I ==> I ==> A
/ \ | |
A I A A
| |
A A
Figure 2: Example of Priority Tree Pruning
In the example in Figure 2, "P" represents a Placeholder, "A"
represents an active node, and "I" represents an inactive node. In
the first step, the server discards two inactive branches (each a
single node). In the second step, the server condenses an interior
inactive node. Note that these transformations will result in no
change in the resources allocated to a particular active stream.
Clients MUST assume the server is actively performing such pruning
and MUST NOT declare a dependency on a stream it knows to have been
closed.
3. Incorporating Placeholders in HTTP/QUIC
HTTP/QUIC [HQ] uses a different PRIORITY frame which already permits
selecting either a stream or a Push ID (a new concept in HTTP/QUIC)
to be prioritized or used as a dependency. Expanding this frame to
support placeholders as well requires additional bits.
The PRIORITY frame currently uses two flag bits to indicate Request/
Push dependencies on Request/Push. If the full matrix of
dependencies is to be supported (Request/Push/Placeholder dependent
on Request/Push/Placeholder), four bits would be required to
represent the space, with several invalid flag combinations being
defined. (If one combination were eliminated, three flags would be
sufficient to represent the remaining combinations, but the semantics
of individual flags would be unclear.)
HTTP/QUIC does not have the implicit closure of streams like HTTP/2.
While client implementations could reset streams which they intend to
use as priority placeholders, there has been interest in creating
greater clarity and synchronization between the client and server
views of the priority tree.
Bishop Expires August 10, 2018 [Page 6]
Internet-Draft Placeholders in HTTP/2 February 2018
4. Security Considerations
This extension is believed to improve security relative to [RFC7540],
as it helps to constrain a previously unbounded state commitment.
5. IANA Considerations
This document registers one new frame type and one new setting.
5.1. SETTINGS_PLACEHOLDERS Setting
The "SETTINGS_PLACEHOLDERS" setting is registered in the "HTTP/2
Settings" registry established in [RFC7540].
Name: SETTINGS_PLACEHOLDERS
Code: 0xSETTING-TBD
Initial Value: not set
Specification: This document.
5.2. PLACEHOLDER_PRIORITY Frame
The "PLACEHOLDER_PRIORITY" frame is registered in the "HTTP/2 Frames"
registry established in [RFC7540].
Name: PLACEHOLDER_PRIORITY
Code: 0xFRAME-TBD
Specification: This document.
6. References
6.1. Normative References
[HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-07 (work in progress), October
2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Bishop Expires August 10, 2018 [Page 7]
Internet-Draft Placeholders in HTTP/2 February 2018
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-07 (work in progress), October
2017.
Appendix A. Acknowledgements
A substantial portion of Mike's work on this draft was supported by
Microsoft during his employment there.
Author's Address
Mike Bishop
Akamai
Email: mbishop@evequefou.be
Bishop Expires August 10, 2018 [Page 8]
