idnits 2.17.1 draft-vkrasnov-h2-compression-dictionaries-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC7540], [RFC1951], [BROTLI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2016) is 2839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Krasnov 3 Internet-Draft CloudFlare Inc. 4 Intended status: Informational July 17, 2016 5 Expires: January 18, 2017 7 Compression Dictionaries for HTTP/2 8 draft-vkrasnov-h2-compression-dictionaries-00 10 Abstract 12 The HTTP/2 [RFC7540] protocol encourages the use of many small assets 13 for CSS/JS/HTML, due to its multiplexed nature. Prior to HTTP/2, 14 asset inlining was encouraged, resulting in fewer, larger assets per 15 website. 17 The nature of the compression algorithms, such as DEFLATE [RFC1951] 18 and Brotli [BROTLI], used with HTTP in practice, require a certain 19 "window" of data to perform backward matching. Therefore, larger 20 files have much better compression ratio. These algorithms also 21 allow the use of custom compression dictionaries which can be used as 22 the initial window for backward matches. 24 This document specifies a new HTTP/2 frame type and a new HTTP/2 25 setting value that would allow a compression algorithm to use 26 previously sent data as a compression dictionary, resulting in an 27 improved compression ratio. 29 Note to Readers 31 A study performed on a actual set of websites in CloudFlare, produced 32 up to 1.50X smaller files, when using DEFLATE (zlib compression level 33 8) with a dictionary, compared to DEFLATE alone. On average, 1.10X 34 smaller files were produced. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 18, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 72 2. HTTP/2 Extension . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. HTTP/2 SETTINGS_ENABLE_DICTIONARIES Setting . . . . . . . 3 74 2.2. The SET_DICTIONARY frame . . . . . . . . . . . . . . . . 3 75 2.3. The USE_DICTIONARY frame . . . . . . . . . . . . . . . . 3 76 2.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 77 2.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 83 1. Introduction 85 The HTTP protocols allow for transmitted data to be compressed with a 86 lossless compression algorithm. The algorithm used is specified in 87 the "Content-Encoding" header field. For example "Content-Encoding: 88 br" means the data was compressed using the Brotli format. 90 The compression, especially of dynamic resources, is a compute-heavy 91 operation, where investing more compute power results in diminishing 92 returns (in terms of compression ratio). One technique known to 93 improve compression ratio significantly, and is supported by many 94 compression formats is the "Compression Dictionary". A "Compression 95 Dictionary" allows the compressor to use a chunk of agreed upon data 96 as the initial sliding window for a given algorithm. 98 This document introduces a mechanism for supplying such a dictionary 99 over HTTP/2 to be used with an underlying compression algorithm. 101 1.1. Requirements Notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. HTTP/2 Extension 109 2.1. HTTP/2 SETTINGS_ENABLE_DICTIONARIES Setting 111 HTTP/2 SETTINGS_ENABLE_DICTIONARIES (0xTBA): This setting can be used 112 to enable the use of Compression Dictionaries for a given connection. 113 The value indicates how many dictionaries are permitted. The initial 114 value is 0, the maximal value is 8. 116 2.2. The SET_DICTIONARY frame 118 The SET_DICTIONARY frame (type=0xTBA). 120 +-------------+-------------+ 121 | Dict ID (8) | Size (8) | 122 +-------------+-------------+ 124 The payload of a SET_DICTIONARY frame contains the following fields: 126 Dict ID: An 8-bit value that specifies the slot for this dictionary. 127 Dict ID must be in the range [0..SETTINGS_ENABLE_DICTIONARIES - 1]. 129 Size: An 8-bit field indicating the size of the dictionary used. The 130 actual size of the dictionary would be 2^Size. The maximal value of 131 Size is 16, with the corresponding window size of 65536 octets. 133 2.3. The USE_DICTIONARY frame 135 The USE_DICTIONARY frame (type=0xTBA). 137 +-------------+ 138 | Dict ID (8) | 139 +-------------+ 141 The payload of a USE_DICTIONARY frame contains the following fields: 143 Dict ID: An 8-bit value that identify the dictionary slot, as set by 144 the SET_DICTIONARY frame. Dict ID must be in the range 145 [0..SETTINGS_ENABLE_DICTIONARIES - 1]. 147 2.4. Server Behavior 149 The server can send the SET_DICTIONARY frame on any stream, before 150 sending the initial DATA frame for that stream. 152 The server may then use the first 2^Size uncompressed octets of that 153 stream as a Compression Dictionary for any subsequent stream. 155 In a typical scenario a server may set a dictionary for each content 156 type, or use the initial stream as a dictionary for all other 157 streams. 159 For every stream compressed with a Compression Dictionary, the server 160 MUST send a USE_DICTIONARY frame, prior to any DATA frame on that 161 stream. 163 The server MAY send several SET_DICTIONARY frames with the same ID. 164 In that case the old Compression Dictionary is replaced by the new 165 one. 167 2.5. Client Behavior 169 Upon receiving a SET_DICTIONARY frame, the client will reserve a slot 170 for a dictionary with a given size. After receiving (and potentially 171 decompressing) the DATA for a given stream, it will store the first 172 2^Size octets of the decompressed DATA in the dictionary. If 2^Size 173 is greater than the size of the decompressed DATA, as many octets as 174 are available will be used. 176 When receiving a USE_DICTIONARY frame, the client will use the 177 specified dictionary to decompress the DATA. 179 A given stream may receive a SET_DICTIONARY and GET_DICTIONARY with 180 the same ID. In that case the stream is decompressed with the old 181 dictionary and then used as the new dictionary. 183 Due to the multiplexed nature of HTTP/2, it may be that a stream with 184 a dictionary will arrive after a stream that uses it. This needs to 185 be taken into account when setting priorities and stream window 186 sizes. 188 3. IANA Considerations 190 This draft currently has no requirements for IANA. If the draft is 191 standardized, the corresponding frames and settings will need to be 192 assigned a type ID. 194 4. Security Considerations 196 Using any kind of compression over TLS may leak information about the 197 plaintext. In that regard using a Compression Dictionary can 198 potentially leak more information than regular use of compression. A 199 special care should be taken when compressing sensetive data. 201 5. References 203 [BROTLI] Alakuijala, J. and J. Szabadka, "Brotli Compressed Data 204 Format", May 2016. 206 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 207 version 1.3", RFC 1951, May 1996. 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, 211 DOI 10.17487/RFC2119, March 1997, 212 . 214 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 215 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 216 DOI 10.17487/RFC7540, May 2015, 217 . 219 Author's Address 221 Vlad Krasnov 222 CloudFlare Inc. 224 Email: vlad@cloudflare.com