idnits 2.17.1 draft-salsano-ictp-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2012) is 4344 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 427, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-05) exists of draft-detti-conet-ip-option-01 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Salsano 3 Internet-Draft A. Detti 4 Intended status: Informational N. Blefari-Melazzi 5 Expires: November 29, 2012 M. Cancellieri 6 Univ. of Rome "Tor Vergata" 7 May 28, 2012 9 ICTP - Information Centric Transport Protocol for CONET ICN 10 draft-salsano-ictp-00 12 Abstract 14 Let us consider an Information Centric Networking (ICN) solution, in 15 which an End Node requests for a content sending "content requests" 16 (or "interest packets"). The content is provided back to the 17 requestor by the "origin" node or by an intermediate node that had 18 cached the content. The content is usually divided into "chunks" 19 that can be individually requested, sent back to the requester, 20 cached into intermediate nodes. The sending rate of content requests 21 can be adjusted in order to perform congestion control, implementing 22 a receiver driven transport protocol. As it can be useful to have 23 large chunks (significantly larger than the Maximum Tranfer Unit 24 across the network), the transport protocol should also be used to 25 further segment the chunks rather than relying to IP fragmentation. 26 In this memo we define ICTP (Information Centric Transport Protocol), 27 a receiver driven transport protocol for ICN, which relies on the 28 CONET ICN solution described in a companion draft. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 29, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. CONET Basics . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. ICTP Data Structures . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Interest CIU Payload Header . . . . . . . . . . . . . . . 5 67 3.2. DATA CIU Payload Header . . . . . . . . . . . . . . . . . 6 68 3.3. EVLE Efficient Variable Length Encoding . . . . . . . . . 7 69 4. ICTP mechanisms . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Congestion control mechanisms . . . . . . . . . . . . . . 9 71 4.1.1. Fast recovery and fast retransmit . . . . . . . . . . 9 72 4.1.2. Slow start and congestion avoidance . . . . . . . . . 9 73 4.2. ICTP specific mechanisms . . . . . . . . . . . . . . . . . 9 74 4.2.1. Prefetch option . . . . . . . . . . . . . . . . . . . 9 75 4.2.2. Request chunk information . . . . . . . . . . . . . . 10 76 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 6. Performance Considerations . . . . . . . . . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 [I-D.CONET] proposes an approach to Information Centric Networking 88 [Koponen07][Jacobson09] based on extending the IP protocol by using a 89 new IP Option called CONET IP option (defined both for IPv4 [RFC0791] 90 and IPv6 [RFC2460]). The CONET IP option can be used by routers to 91 support content aware networking, in addition to classical address 92 based networking. Further information on the proposed solution can 93 also be found in [CONET11]. 95 In this memo we define a receiver driven transport protocol for CONET 96 ICN, called ICTP - Information Centric Transport Protocol. The 97 transport protocol is able to provide a reliable transfer of the 98 content and to perform congestion control in TCP-friendly way. A 99 discussion about the definition of a transport protocol for ICN can 100 be found in [ICTP12]. 102 As shown in Figure 1, the CONET architecture proposed in [I-D.CONET] 103 foresees End-Nodes, Serving Nodes and CONET nodes. End-Nodes request 104 for content. Serving Nodes provide content. CONET nodes: i) forward 105 content requests from End-Nodes to Serving Nodes; ii) deliver content 106 from Serving Nodes to End-Nodes; iii) may cache content and therefore 107 provide it to End-Nodes without contacting the Serving Node. 109 requests for content 110 -------------------> 111 content is provided 112 <------------------- 113 +----+ +----+ +----+ 114 | | --| |------| | 115 +----+\ / +----+ +----+ 116 \ +----+ +----+ / 117 ----| |------| |/ 118 +----+ +----+ 119 End-Node legacy Intermediate Border Serving 120 IP router Node Node Node 121 | | 122 +---------CONET next hop----------->+ 124 Figure 1: CONET architecture 126 2. CONET Basics 128 In this section we recall the basic aspects of the CONET ICN 129 solution, as needed to introduce the proposed receiver driven 130 Information Centric Transport Protocol (ICTP). 132 The figure below shows the CONET protocol stack. CONET protocol is 133 divided in two sub-layers, whose data unit are respectively denoted 134 as "Carrier Packets" and "CONET Information Units". Two types of 135 CONET Information Units are currently defined ("Interests CIU" and 136 "Named Data CIU"). The CONET Information Unit Type field in the 137 CONET IP option differentiates among the two types. A CONET 138 Information Unit (CIU) can be split into different Carrier Packets. 139 Each Carrier Packet is transported by an IP packet. 141 +--------+--------+--------+ \ 142 | CONET Information Units | | 143 +--------+--------+--------+ | 144 | 145 +--------+--------+--------+ |- CONET protocol 146 | Carrier Packets | | 147 +--------+--------+--------+ | 148 | 149 +--------+--------+--------+ / 150 | IP (with CONET IP option)| 151 +--------+--------+--------+ 153 Figure 2: CONET protocol layers 155 The generic structure of a Carrier Packet (CP) is reported hereafter: 157 +-------------------------+ 158 | CP Payload header | 159 +-------------------------+ 160 | CP Payload | 161 +-------------------------+ 162 | CP Path state | 163 +-------------------------+ 165 "Interest CIU" are used by End-Nodes to request for content. The 166 Interest CIUs contain the identifier of the content called ICN-ID and 167 transported within the IP CONET Option. Optionally, the IP CONET 168 option can explicitly carry a "Chunk Sequence Number" to identify one 169 of the chunk in which a content has been split. Another possibility 170 is that the chunk number is carried within the ICN-ID itself. A 171 Serving Node or a CONET node that had previously cached the 172 information can reply to the content request by sending a "Named-data 173 CIU". These Named-data CIU will also contain the ICN-ID in the IP 174 CONET Option. 176 The CP payload header contains the length of the CP Payload and 177 allows to identify the start of the CP Path state field. The use of 178 CP Path state field was explained in [I-D.CONET] and is out of scope 179 here. 181 The information contained in the CP Payload header is specific for 182 each CIU type. The information transported in the CP Payload header 183 can be used to implement the functionalities of a transport protocol, 184 providing a reliable transmission of content and performing 185 congestion control. In this document we define the CP Payload header 186 for Interest and Data CIUc using the ICTP protocol. 188 An end-node that wants to retrieve a content (or better a Chunk of a 189 content) issues an Interest CIU, the ICN-ID and (optionally) the 190 Chunk Sequence Number of the required Content are respectively 191 transported in the ICN Identifier (ICN-ID) field and in the CSN field 192 of the CONET IP option. Assuming for simplicity that the Interest 193 CIU will fit into a single Carrier Packet, the Interest CIU will be 194 included in the Carrier Packet that in turn is inserted into an IP 195 packet. The ICTP comes into play because a Chunk of content may need 196 to be fragmented in more than one Carrier Packet, as the chunk size 197 can be much larger than the layer 2 MTU. For example with a chunk 198 size of 64 KB or 256 KB and an MTU of 1500 bytes, the chunks need to 199 be split in tens or hundreds of packets. In this case the RDTP 200 allows to specify in the request the specific segment of the chunk 201 that is required. 203 3. ICTP Data Structures 205 3.1. Interest CIU Payload Header 207 The structure of the interest CP payload header is reported 208 hereafter: 210 +-------------------------+ 211 |TTrrrrrPI| ..Left Edge...| 212 +-------------------------+ 213 | ...Right Edge... | 214 +-------------------------+ 216 Flags: 218 TT : Transport protocol type. It allows to define different 219 transport protocols. 0 indicates ICTP which is defined in this draft. 220 1-3 are reserved and can be used to indicate different transport 221 protocols. The rest of the bits in this field and in the following 222 bytes may have a different semantic depending on the transport 223 protocol, we are providing here only the defintion for TT=0 i.e. the 224 ICTP protocol. Therefore the number of transport protocols is NOT 225 limited to 4. 227 P : Prefetch flag - This flag indicates that this packet comes from a 228 receiver that asks to perform prefetch on the content chunks. 230 I : Ask Chunk Info flag - If this flag is set, the serving node is 231 requested to add chunk-related information to the data CIU payload, 232 particularly the chunk size. 234 Left edge/Right edge : These fields contain respectively the value of 235 first and the last byte of the requested chunk segment. The fields 236 are encoded with the EVLE (Efficient Variable Lenght Encoding) 237 mechanim described below 239 3.2. DATA CIU Payload Header 241 The structure of the data CP payload header is reported hereafter: 243 +-------------------------+ 244 |TTrFSSSS| ...Left Edge...| 245 +-------------------------+ 246 | ...Right Edge... | 247 +-------------------------+ 248 | (Optional) Chunk size | 249 +-------------------------+ 251 Flags: 253 TT : Transport protocol type. It allows to define different 254 transport protocols. 0 indicates ICTP which is defined in this draft. 255 1-3 are reserved and can be used to indicate different transport 256 protocols. The same considerations apply that have been reported 257 above for the TT subfield in the interest CIU payload header. 259 F : Final segment flag - If this bit is set to 1 this carrier packet 260 carries the last segment of a chunk. 262 SSSS : Chunk size flag - This flag describes the size of a chunk as 263 follows: 265 0 : unspecified (it may have been already indicated 266 in a previous data) 267 1 : the chunk size is trasnported in the optional 268 Chunk size field, encoded with the EVLE variable length 269 encoding described below 270 2-16 : let n be the value from 2 to 16, it can represent 271 14 different chunk sizes from 2KBytes to 8Mbyte 272 with the following relation: 273 chunk size = 2 ^ (9+n) 275 Left edge/Right edge : These fields contains respectively the value 276 of first and the last byte of the transported chunk segment. The 277 fields are encoded with EVLE variable length encoding described 278 below. These fields carry the actual value of the segment 279 transported that may differ from the request. 281 3.3. EVLE Efficient Variable Length Encoding 283 Some of the fields described above are encoded using a variable 284 lenght encoding that we denote as "Efficient Variable Lenght 285 Encoding". The same encoding is used for the Chunk Sequence Number 286 (CSN) field in the CONET IP Option, as described in [I-D.CONET]. To 287 help the reader, we report the definition of the encoding hereafter. 288 An EVLE field is represented with a variable number of bytes. An 289 initial bit pattern determines the length of the EVLE field. 291 1 byte EVLE (7 bits range) 292 +--------+ 293 |0 | 294 +--------+ 296 2 bytes EVLE (15 bit range) 297 +--------+--------+ 298 |10 | 299 +--------+--------+ 301 3 bytes EVLE (21 bit range) 302 +--------+--------+--------+ 303 |110 | | | 304 +--------+--------+--------+ 306 4 bytes EVLE (28 bit range) 307 +--------+--------+--------+--------+ 308 |1110 | | | | 309 +--------+--------+--------+--------+ 311 5 bytes EVLE (32 bit range) 312 +--------+--------+--------+--------+ 313 |11110000| | | | 314 +--------+--------+--------+--------+ 315 | | 316 +--------+ 318 6 bytes EVLE (40 bit range) 319 +--------+--------+--------+--------+ 320 |11110001| | | | 321 +--------+--------+--------+--------+ 322 | | | 323 +--------+--------+ 325 As explained in in [I-D.CONET], binary patterns from 11110010 to 326 11111111 are reserved and could be used to extend the EVLE range if 327 needed. With the above definion the maximum value is 2^40, roughly 1 328 Tera. 330 4. ICTP mechanisms 332 The transport protocol described in this draft mimics the TPC 333 mechanisms described in [RFC2581], with the required adaptations for 334 a receiver driven approach. In fact, while in TCP the sender sends 335 data segment and implements retransmissions and congestion control 336 based on the reception of ACKs, in ICN based content download the 337 receiver asks for content sending the Interests and implements re- 338 sending of Interests and congestion control based on the reception of 339 Data. 341 4.1. Congestion control mechanisms 343 4.1.1. Fast recovery and fast retransmit 345 The receiver bases its flow control on the received data CP. The out 346 of sequence recognition is based on the expected chunk number and 347 segment bytes. When three out-of-sequence data CP are received the 348 slow start threshold (ssthresh, see [RFC2581]) is set to half the 349 window plus the 3 data carrier packet already received and the 350 interest for the missing segment is retransmitted. 352 4.1.2. Slow start and congestion avoidance 354 To manage the increase of congestion window slow start and congestion 355 avoidance mechanism are performed. During slow start, (e.g. the 356 beginning of the connection), the congestion window increases of an 357 amount equal to the received data CP. This corresponds to an 358 "exponential" growth of the window. During congestion avoidance, the 359 growth of the window is aproximately "linear" with time. Let us 360 define a "segment" as the portion of content transported in a data 361 CP. We define the congestion window cwnd in segments. During slow 362 start cwnd = cwnd + 1 for each received data CP. During congestion 363 avoidance cwnd = cwnd + 1/cwnd for each received data CP. 365 4.2. ICTP specific mechanisms 367 4.2.1. Prefetch option 369 In a ICN based network, we can have applications separately 370 requesting the download of each chunk of content. In our ICTP 371 approach this means that we can only request the segments of a given 372 chunk after that we have received the request for the chunk coming 373 from the application. The application may implement retransmission 374 and congestion control, therefore the ICTP could receive requests for 375 more than a chunk of the same content in parallel. Anyway the 376 interaction between the congestion control performed at application 377 level and the congestion control performed at ICTP level could prove 378 inefficient. Therefore we believe that the API offered to the 379 application should allow the application to request for a whole 380 content (or for the content starting from a given chunk number). 381 Then the ICTP protocol can handle the retrieval of all the (rest of) 382 the content. Therefore the ICTP protocol offers also a "prefetch 383 option". Whit the prefetch option active, if the congestion window 384 has space left, the mechanism allow to issue requests for segments of 385 next expected chunks, without waiting for an explicit request from 386 application level. 388 4.2.2. Request chunk information 390 When the transmission start, the receiver must issue a request for at 391 least the chunk size. Receiver should set the flags in carrier 392 packet accordingly to Section 3.1. The data ciu requested will carry 393 at least the chunk size, receiver should use this information to 394 create data structure best suited for the chunk size. 396 5. Acknowledgments 398 We acknowledge the financial support by the EU in the context of the 399 CONVERGENCE research project. 401 6. Performance Considerations 403 7. IANA Considerations 405 This document requires the allocation of one IP option by the IANA. 407 This document requires the allocation of one IP protocol number by 408 the IANA. 410 This document requires that IANA will maintain the registry of CONET 411 namespaces. 413 8. Security Considerations 415 Security considerations to be provided 417 9. References 419 9.1. Normative References 421 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 422 September 1981. 424 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 425 (IPv6) Specification", RFC 2460, December 1998. 427 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 428 June 1999. 430 9.2. Informative References 432 [CONET11] A. Detti, et al., "CONET: A Content Centric Inter- 433 Networking Architecture", ACM SIGCOMM Workshop on 434 Information-Centric Networking (ICN-2011), Toronto, 435 Canada , August 2011. 437 [I-D.CONET] 438 Detti, A., Salsano, S., and N. Blefari-Melazzi, "An IPv4 439 Option to support Content Networking", 440 draft-detti-conet-ip-option-01 (work in progress), 441 September 2011. 443 [ICTP12] S. Salsano, et al., "Transport-layer issues in Information 444 Centric Networks", ACM SIGCOMM Workshop on Information- 445 Centric Networking (ICN-2012), Helsinki, Finland , 446 August 2012. 448 [Jacobson09] 449 V. Jacobson, et al., "Networking named content", Proc. of 450 ACM CoNEXT 2009 , 2009. 452 [Koponen07] 453 T. Koponen et al., "A data-oriented (and beyond) network 454 architecture", Proc. of ACM SIGCOMM 2007 , 2007. 456 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 457 Control", RFC 2581, April 1999. 459 Authors' Addresses 461 Stefano Salsano 462 Univ. of Rome "Tor Vergata" 463 Via del Politecnico, 1 464 Rome 00133 465 Italy 467 Email: stefano.salsano@uniroma2.it 468 Andrea Detti 469 Univ. of Rome "Tor Vergata" 470 Via del Politecnico, 1 471 Rome 00133 472 Italy 474 Email: andrea.detti@uniroma2.it 476 Nicola Blefari-Melazzi 477 Univ. of Rome "Tor Vergata" 478 Via del Politecnico, 1 479 Rome 00133 480 Italy 482 Email: blefari@uniroma2.it 484 Matteo Cancellieri 485 Univ. of Rome "Tor Vergata" 486 Via del Politecnico, 1 487 Rome 00133 488 Italy 490 Email: matteo.cancellieri@gmail.com