idnits 2.17.1 draft-liu-decade-subscription-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 12, 2012) is 4429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-decade-problem-statement' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-decade-survey' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'I-D.gu-decade-reqs' is defined on line 321, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-05 == Outdated reference: A later version (-10) exists of draft-ietf-decade-arch-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE H. Liu 3 Internet-Draft Yale University 4 Intended status: Informational Mar 12, 2012 5 Expires: September 13, 2012 7 Data Streaming Subscription in DECADE 8 draft-liu-decade-subscription-01 10 Abstract 12 This document describes a potential performance issue in DECADE to 13 support real-time applications. It shows the current content hashing 14 based naming scheme might harm the performance when the content data 15 is generated in real time and low propagation latency of the data is 16 required. This draft propose a new naming scheme and protocol, 17 subscribe/unsubscribe, for real-time applications to address the 18 problem caused by content hashing. DECADE clients use subscribe/ 19 unsubscribe to express their interests to receive data streaming. 20 DECADE servers pro-actively push stream data to eligible clients, 21 which saves the time consumed on exchanging the hashing of new 22 generated data. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problems of Content Hash Only Naming for Real-time 61 Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Subscribe/Unsubscribe . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Work Flow of Stream Subscription . . . . . . . . . . . . . 5 64 3.2. Stream ID . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Stream Token . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. Stream Forwarding Table . . . . . . . . . . . . . . . . . . 6 67 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Existing DECADE protocol identifies all the objects by their content 78 hashes. A client cannot fetch an object from DECADE servers until it 79 learns the hash of this object. This property introduces additional 80 delays in "real-time applications", e.g. live streaming, video 81 conference, etc., in which data is generated on the fly and short 82 latency is required to distribute data to clients. 84 This draft discusses about the performance loss of real-time 85 applications with existing DECADE protocol. Moreover it presents a 86 new mechanism "subscribe/unsubscribe" in DECADE framework to better 87 support real-time applications. 89 1.1. Concepts 91 1.1.1. Real-time Applications 93 The applications that have a source generating live data and deliver 94 the data to the receivers with latency as short as possible. 96 1.1.2. DECADE Sender 98 An end host which uploads data to a DECADE server and leverages 99 DECADE framework to deliver the data to one or multiple DECADE 100 receivers. 102 1.1.3. DECADE Receiver 104 An end host which downloads data from DECADE servers. 106 2. Problems of Content Hash Only Naming for Real-time Applications 108 In naming schemes only based on content hashing, an object is 109 identified uniquely by its hash of its content. In other words, if a 110 client wants to download an object, it should firstly learn the 111 object's hash value and send a request to DECADE servers with this 112 hash. This works well in "offline" applications, such as file 113 sharing and video on demand, in which the objects and their hashes 114 already exist, and the object delivery performance is not delay 115 sensitive. However, it will introduces significant additional delays 116 which harms "real-time" application performance. 118 .---------.<--------. 119 .---------> | S | \ 120 1. Upload / `---------'--------. \ 3.Request 121 Object / 4. Download \ \ Object 122 / Object \ \ 123 / v \ 124 .---------------. 2. Token of Object .-----------------. 125 | DECADE Sender |---------------------------->| DECADE Receiver | 126 | (Speaker) | | (Listener) | 127 `---------------' `-----------------' 129 Figure 1: Real-time Object Distribution with Traditional DECADE 131 Figure 1 illustrates a simple case of voice over IP (VoIP) using 132 content hash only naming. When the client on the left is a speaker. 133 It wants to upload only one copy of its voice data to DECADE server S 134 and asks S to upload the data to multiple listeners. The work flow 135 is as the following: (1) The speaker buffers its voice data until its 136 size meets the minimum object size requirement in DECADE (or in the 137 application). Denote D_buffer as the delay caused by the buffering; 138 (2) The speaker uploads the object to S (with delay D_up) and in the 139 meanwhile sends the token to the receiver (with delay D_token); (3) 140 With the token, the listener requests and downloads the object from S 141 (with delay D_down which is the RTT between S and the listener). In 142 summary, the total latency from the moment a piece of voice is 143 generated to the moment this piece reaches the listener side is D_1 = 144 D_buffer + max(D_up, D_token) + D_down. 146 .---------. 147 .---------> | S |--------. 148 1. Up-Stream / `---------' \ 2.Down-Stream 149 / \ 150 / \ 151 / v 152 .---------------. .-----------------. 153 | DECADE Sender | | DECADE Receiver | 154 | (Speaker) | | (Listener) | 155 `---------------' `-----------------' 157 Figure 2: Real-time Streaming with A Simple Forwarding Server 159 Compare with an alternative design shown in Figure 2. If the speaker 160 just pushes data to S and S pushes data to listenrs, the total 161 latency is only D_2 = D_up + D_down/2. D1 - D2 >= D_buffer + 162 D_down/2. In reality, D1 can be much larger than D2. In paricular, 163 D1 can be larger than typical delay threshold (say 200 ms) for VoIP's 164 continulity, while D2 is not. 166 Therefore, to better support real-time applications in DECADE, we 167 propose a new protocol flow to achieve the ideal case in Figure 2 168 compatibly with existing DECADE framework and with scalability and 169 manageability. 171 3. Subscribe/Unsubscribe 173 A stream is a special object whose length we do not know and whose 174 hash does not exist. This is the fundamental reason that content- 175 hash only naming cannot support live streaming well. In this section 176 we propose a new type of protocol subscribe/unsubscribe to support 177 streams in DECADE. There are two key ideas in this new protocol: (1) 178 DECADE servers push stream data to the subscribers; (2) Tokens are 179 used to authorize the eligibility of stream subscriptions. 181 3.1. Work Flow of Stream Subscription 183 Figure 3 illustrates an example of how subscribe/unsubscribe works. 184 At the beginning, the speaker on the left sends a stream creating 185 message to its DECADE server S1 and S1 will allocate a stream ID for 186 the speaker. Then, the speaker uses this stream ID to construct 187 tokens and upload stream data to S1. After the listener gets the 188 stream token, it presents the token in its subscription of the 189 stream. Its DECADE server S2, if S2 is not S1, will recursively 190 subscribe the stream from S1 with the token. Finally if the 191 subscription is authorized, S1 will forward the stream to S2 and S2 192 in turn push the stream to the listener. For scalability and 193 robustness, a stream token might only valid for a duration. The 194 listener should update the stream token periodically from the 195 speaker. When the listener does not want to receive the stream any 196 more, it unsubscribes the stream from S2. When S2 finds there is no 197 subscribers for the stream, it will unsubscribe the stream from S1. 199 2. Up-Stream .----. .----. 4.Down-Stream 200 .======> | S1 | ====> | S2 | ============. 201 // .---> `----` <---- `----` <--------. \\ 202 // / \ \\ 203 // / 1. Create 3. Subscribe \ \\ 204 // v Stream (Token) v v 205 .---------------. .-----------------. 206 | DECADE Sender | <------------------------> | DECADE Receiver | 207 | (Speaker) | Stream Token Update | (Listener) | 208 `---------------' `-----------------' 210 Figure 3: Work Flow of Stream Subscription 212 3.2. Stream ID 214 Each stream must has a unique ID. One possible solution is that each 215 DECADE provider owns a unique prefix for the streams created on its 216 DECADE servers. And the DECADE provider guarantees the uniqueness of 217 streams inside its DECADE network itself. 219 The requirement for the length of stream ID is the same with the 220 object ID defined in [I-D.ietf-decade-arch] 222 3.3. Stream Token 224 Stream Tokens have the same format of DECADE token defined in 225 [I-D.ietf-decade-arch]. In streaming tokens, the "object ID" part is 226 actually stream ID. DECADE servers use stream token to figure out 227 when a subscriber's account is eligible to receive the stream. 229 3.4. Stream Forwarding Table 231 The DECADE server creates a streaming forwarding table to manage and 232 forward streams. When a DECADE client creates a stream in its DECADE 233 server, it actually sets up an item in the server's stream forwarding 234 table. As shown in Figure 4, the key of each item in the table is 235 stream ID. With a stream ID, the server can obtain the owner of the 236 stream which is used to authorize tokens in subscriptions and account 237 resource usage. The server can also learn the current subscribers of 238 the stream and decide where to forward a stream or when to 239 unsubscribe a stream (after the subscriber list becomes empty.) 241 .=============.=================================. 242 | Key | Values | 243 .-------------.---------------------------------. 244 | Stream ID 1 | Owner Account | Subscriber List | 245 .-------------.---------------------------------. 246 | Stream ID 2 | Owner Account | Subscriber List | 247 .=============.=================================. 249 Figure 4: Stream Forwarding Table in DECADE Servers 251 Note that only the DECADE server or DECADE provider (e.g. S1 in 252 Figure 3) on which a stream is created has the stream owner account 253 information. For other DECADE servers or providers (e.g. S2 in 254 Figure 3), they only maintain subscribers who subscribe the stream 255 via themselves. 257 4. Protocol 259 This section shows an example of DECADE subscription protocol on 260 HTTP. 262 As shown in Figure 5, in the subscription request, the client puts 263 the stream ID into the URL. The "Connection" header should be "Keep- 264 Alive" to establish a persistent with the DECADE server. There are 265 two new HTTP headers for DECADE: (1) "Decade-Origin" which indicates 266 the backup location where the stream can be fetched, and (2) "Decade- 267 Token" which presents the token for access the stream to the DECADE 268 server. 270 The server status uses code 200 (OK), 404 (Not Found) or 401 271 (Unauthorized) to tell the clients the result of the subscription. 272 If the subscription is accepted, the server will push streaming data 273 to the client. Otherwise, the server closes the connection. 275 GET /StreamID HTTP/1.1 276 Connection: Keep-Alive 277 Host: server1.decade.net 278 Decade-Origin: http://server2.decade.net 279 Decade-Token: TWFuIGlzIGRpc3Rpbmd 281 Figure 5: A Message of DECADE Streaming Subscription Request 283 HTTP/1.1 200 OK 284 Connection: Keep-Alive 285 Content-Type: application/octet-stream 287 streaming data 289 Figure 6: A Message of DECADE Streaming Subscription Response 291 5. Security Considerations 293 This document does not contain any security considerations. 295 6. IANA Considerations 297 This document does not have any IANA considerations. 299 7. References 301 7.1. Normative References 303 7.2. Informative References 305 [I-D.ietf-decade-problem-statement] 306 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 307 Application Data Enroute (DECADE) Problem Statement", 308 draft-ietf-decade-problem-statement-05 (work in progress), 309 February 2012. 311 [I-D.ietf-decade-survey] 312 Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 313 network Storage Systems", draft-ietf-decade-survey-06 314 (work in progress), August 2011. 316 [I-D.ietf-decade-arch] 317 Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, 318 "DECADE Architecture", draft-ietf-decade-arch-04 (work in 319 progress), October 2011. 321 [I-D.gu-decade-reqs] 322 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 323 Requirements", draft-gu-decade-reqs-05 (work in progress), 324 July 2010. 326 Author's Address 328 Hongqiang Liu 329 Yale University 331 Email: hongqiang.liu@yale.edu