idnits 2.17.00 (12 Aug 2021) /tmp/idnits18131/draft-aboba-unweb-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 116 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 160 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...), its areas...' == Line 11 has weird spacing: '... its worki...' == Line 15 has weird spacing: '... and may ...' == Line 19 has weird spacing: '... To learn...' == Line 21 has weird spacing: '...ctories on ...' == (111 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 255, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 262, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 265, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 269, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 273, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 276, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 279, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 282, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 286, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) == Outdated reference: A later version (-05) exists of draft-speer-avt-layered-video-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: draft-ietf-mhtml-spec has been published as RFC 2110 == Outdated reference: draft-ietf-mhtml-related has been published as RFC 2112 == Outdated reference: A later version (-11) exists of draft-ietf-mhtml-info-03 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: draft-ietf-http-v11-spec has been published as RFC 2068 == Outdated reference: A later version (-02) exists of draft-crowcroft-rmfp-00 -- Possible downref: Normative reference to a draft: ref. '9' -- Unexpected draft version: The latest known version of draft-parnes-rtp-ext-srm is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 25 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Bernard Aboba 3 Microsoft Corporation 5 Requirements for Unreliable Multicasting of Web Resources 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working docu- 10 ments of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute work- 12 ing documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 The distribution of this memo is unlimited. It is filed as , and expires October 1, 1997. Please send com- 26 ments to the authors. 28 2. Abstract 30 This document discusses applications for unreliable multicasting of 31 Web resources as well as requirements for an unreliable multicast pro- 32 tocol suitable for this use. 34 3. Introduction 36 3.1. Purpose 38 Many Web sites that distribute popular, frequently updated content 39 experience problems with "flash crowds": thousands of access per 40 minute to the same Web page overload the Web server or the network 41 link leading to the server. Moreover, with the increasing growth of 42 "push" technology, it is likely that these problems will get worse, 43 not better. 45 It is possible that IP multicasting of Web resources may be used both 46 to solve serious existing operational problems like "flash crowds", 47 and to avoid creating new problems due to "server push" applications. 48 Several applications appear to be naturally amenable to use of unreli- 49 able multicast. 51 In this context, unreliable refers to applications where a repair 52 mechanism is not required. These are typically applications where the 53 material is of time value (stock tickers), so that it makes more sense 54 to wait for the resource to be re-multicast than to attempt to repair 55 it; applications in which an alternative means is available for 56 retrieving the resource (cache filling); applications in which error 57 correction is performed at the datalink layer; or applications in 58 which a separate error correction stream is transmitted along with the 59 data, typically on a separate group. 61 In a cache filling application, there is a relatively small probabil- 62 ity that a particular missing resource will be hit, and so it is often 63 more costly to request a repair than to leave an incompletely received 64 resource in the cache, where it may never be requested. Cache hits 65 when they do occur, will typically be spread out over time, and there- 66 fore not synchronized to the original transmission. As a result, such 67 applications present no danger of a NAK implosion. 69 4. Requirements 71 The requirements for unreliable multicast transmission of Web 72 resources are as follows: 74 Transport issues 75 Robustness 76 Prioritization 77 Low overhead 78 Encapsulation issues 79 Source differentiation 80 Resource demultiplexing 81 Receiver reporting 82 Sender reporting 83 Layered encoding 84 Need for an encoded clock 86 4.1. Transport issues 88 4.1.1. Robustness 90 It is desirable that an unreliable Web multicast scheme be efficient 91 in transmission of small as well as large resources. 93 Where transmission of large resources is required, unreliable multi- 94 casting techniques may be quite effective. For example, in a cache 95 filling application where 80 percent of the file has been received 96 prior to a cache miss, 80 percent of the bandwidth required to 97 retrieve the resource would have been saved, which would greatly out- 98 weigh the cost of the connection setup for the subsequent cache miss. 100 However, most Web resources are in the 1 Kbyte to 10 Kbyte range, and 101 so if the profile of resources transmitted via unreliable Web 102 multicasting were to more resemble the average, then an optimized 103 encapsulation is likely to require from 2 to 20 packets. In this case 104 unsophisticated unreliable multicast schemes are likely to be highly 105 vulnerable to packet loss. The effect of packet loss may be mitigated 106 by a number of techniques, including utilization of an error correc- 107 tion channel, as well as use of a data carousel, possibly operating 108 with offset layering. 110 The use of an error correction channel is only likely to be effective 111 for non-burst errors. Where errors are relatively uncorrelated, the 112 effect of packet loss may be mitigated at the expense of additional 113 overhead proportional to the loss rate. To allow receivers to sub- 114 scribe to an error correction channel up to their estimated loss rate, 115 it is necessary for the transmission rate to be sufficiently below the 116 channel capacity so as to allow for the receiver to subscribe to the 117 transmission as well as to the required error correction group. 119 Where burst errors are present, error correction channels will not be 120 very effective and the resulting reception time will increase. If 121 packet loss rates are substantial, then many revolutions of the data 122 carousel will be required since on each revolution of the carousel the 123 chance of completing the transmission will be small. Thus, after a 124 certain number of carousel revolutions, it probably makes sense to 125 stop listening. Thus in an unreliable multicast transmission there is 126 a distinct possibility that the transmission will not complete, and 127 the application must be able to deal with this effectively. 129 4.1.2. Prioritization 131 In situations where "flash crowds" are anticipated, it is desirable to 132 encourage use of unreliable Web multicasting, possibly at the expense 133 of unicast retrievals of the same resource. As a result, it will be 134 desirable for unreliable Web multicasts to reside on a high priority 135 multicast port; in addition, it may be desirable for this traffic to 136 be prioritized above unicast HTTP. 138 4.1.3. Low Overhead 140 Since resource multicasting will typically use a small MTU size (i.e. 141 536 octets), it is important that a low overhead encapsulation be cho- 142 sen. In order to achieve this, the URL must not be sent in every 143 packet. In addition, it may be desirable to support header compres- 144 sion. 146 4.2. Encapsulation issues 147 4.2.1. Source differentiation 149 Since mixing is not useful for transmission of Web resources, and 150 allowing multiple sources would make it difficult to maintain rate 151 control, it is likely that only one source will be sending to a group 152 at one time. Nevertheless, in the case where there is a handoff, it is 153 necessary to be able to differentiate sources, since packets from the 154 two sources may be intermingled. However, it appears that this source 155 differentiation can be accomplished using the source IP address and 156 port, without requiring a source ID in addition. 158 4.2.2. Resource demultiplexing 160 For multicast resource transmission, it desirable to be able to reuse 161 a group and port for the sending of multiple resources. Resources are 162 typically of small size, and therefore the overhead of obtaining a 163 group address and setting up the transmission would be excessive. 164 Since it is possible for packets from one resource to become intermin- 165 gled with another due to out of order delivery, it is necessary to be 166 able to demultiplex resources sent from a single source. However, it 167 is typically undesirable to have to include the resource URL in every 168 packet, since packets will typically be small, and URLs may be large. 169 Therefore a resource ID is likely to be required. 171 4.2.3. Receiver reporting 173 Even though we are discussing unreliable transmission, some kind of 174 receiver feedback is likely to be desirable. Such feedback can be 175 used to estimate listenership, packet loss rates, and receiver band- 176 width availability. Jitter is not likely to be a useful metric for 177 reception quality in this case. 179 Typically, receiver reporting information will be used both for engi- 180 neering purposes (diagnosis of transmission problems) as well as for 181 business purposes (listenership information). While receiver reports 182 could be useful in allowing senders to adjust transmission parameters, 183 typically it is more desirable to allow receiver-driven rate adapta- 184 tion via layered encoding. 186 By transmitting a resource on several groups, each starting transmis- 187 sion with a different offset, the receiver may adjust their reception 188 rate based on the available bandwidth. Typically, the group transmis- 189 sion rates will be tailored to commonly available bandwidths, i.e. 10 190 Kbps for 14.4 Kbps modems, 20 Kbps for 28.8 Kbps, 30 Kbps for single 191 channel ISDN, etc. 193 Sender-driven transmission rate adjustment appears to be useful in 194 only a limited number of circumstances. In cases where a small frac- 195 tion of listeners are experiencing problems, it is undesirable to 196 adjust the transmission rate; instead, the affected receivers should 197 adjust their rate by leaving the higher bandwidth groups. If this 198 does not work, they should stop listening to the transmission 199 altogether. 201 A circumstance in which sender-driven transmission rate adjustment 202 appears useful is in the case where the majority of listeners are only 203 subscribed to the lowest transmission rate group, yet appear to lack 204 the bandwidth to also join an error correction group appropriate to 205 their packet loss rate. In this case the sender should back off the 206 transmission rate on the lowest group to allow for successful recep- 207 tion of the error correction information. 209 As there are applications in which receiver feedback may not be feasi- 210 ble or desirable (satellite transmission), it must be possible to turn 211 off the receiver reporting mechanism if desired. 213 4.2.4. Sender reporting 215 Just as receivers may wish to provide feedback to senders, so may 216 senders wish to provide instructions to receivers. This may include 217 information about the particular resource being transmitted (such as 218 the resource length, related keywords, or URL), or information on the 219 status of the transmission itself, such as the highest offset trans- 220 mitted. 222 4.2.5. Layered encoding 224 Layered multicasting appears to be essential for multicast transmis- 225 sion of resources, since it provides for receiver-driven rate adapta- 226 tion, as well as for transmission of error-correction information. 227 While layered encoding was originally proposed for use in audio/video 228 transmission, it can also be applied to data carousel style transmis- 229 sions. In this application, each of the layers transmits the same 230 resource, beginning at a different offset. Receivers with sufficient 231 bandwidth may then subscribe to multiple groups, and receive the 232 resource more quickly. 234 Layered encoding may also provide for error correction, by allowing 235 error correction information to be transmitted on separate groups. 236 Receivers may then subscribe to these groups according to their aver- 237 age packet loss rate; receivers experiencing high loss rates will typ- 238 ically join a higher bandwidth error correction group. In order to 239 allow for the additional bandwidth of an error correction group, the 240 sender transmission rate should be set appropriately. 242 4.2.6. Need for an encoded clock 244 Most uses of unreliable resource multicasting do not have realtime 245 requirements, and as a result, it is not envisaged that unreliable 246 multicasting of Web resources requires an encoded clock. 248 5. Acknowledgements 250 Thanks to Harald.T.Alvestrand, Jim Gemmell, Paul Leach and Thomas 251 Pfenning for useful discussions of this problem space. 253 6. References 255 [1] R. Braden. "Requirements for Internet hosts - application and 256 support." STD 3, RFC 1123, IETF, October 1989. 258 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A 259 Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, 260 January 1996. 262 [3] H. Schulzrinne. "RTP Profile for Audio and Video Conferences 263 with Minimal Control." RFC 1890, GMD Fokus, January 1996. 265 [4] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia 266 Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, 267 LBNL, June 1996. 269 [5] J. Palme, A. Hopmann. "MIME E-mail Encapsulation of Aggregate 270 Documents, such as HTML (MHTML)." draft-ietf-mhtml-spec-03.txt, 271 Stockholm University/KTH, ResNova Software, August, 1996. 273 [6] E. Levinson. "The MIME Multipart/Related Content-type." draft- 274 ietf-mhtml-related-00.txt, Xison, May, 1996. 276 [7] J. Palme. "Sending HTML in E-mail, an informational supplement." 277 draft-ietf-mhtml-info-03.txt, Stockholm University/KTH, August, 1996. 279 [8] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." 280 draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. 282 [9] J. Crowcroft, Z. Wang, A. Ghosh, C. Diot. "RMFP: A Reliable Mul- 283 ticast Framing Protocol." draft-crowcroft-rmfp-00.txt, UCL, November, 284 1996. 286 [10] P. Parnes. "RTP Extension for Scalable Reliable Multicast." 287 draft-parnes-rtp-ext-srm-01.txt, LuTH/CDT, November, 1996. 289 7. Authors' Addresses 291 Bernard Aboba 292 Microsoft Corporation 293 One Microsoft Way 294 Redmond, WA 98052 296 Phone: 206-936-6605 297 EMail: bernarda@microsoft.com