idnits 2.17.1 draft-salsano-ictp-02.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 (June 20, 2013) is 3962 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 435, 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) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 2 errors (**), 0 flaws (~~), 2 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: December 22, 2013 M. Cancellieri 6 Univ. of Rome "Tor Vergata" 7 June 20, 2013 9 ICTP - Information Centric Transport Protocol for CONET ICN 10 draft-salsano-ictp-02 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 December 22, 2013. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . 8 71 4.1.1. Fast recovery and fast retransmit . . . . . . . . . . 8 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 . . . . . . . . . . . . . . 9 76 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 [I-D.CONET] proposes an approach to Information Centric Networking 88 [Koponen07][Jacobson09]. It proposed to extends the IP protocol 89 suite by defining a new IP Protocol type (CONET). Then it proposes 90 two ways of carring ICN related information in IP packets, one uses a 91 new IP Option (both for IPv4 [RFC0791] and IPv6 [RFC2460]), the other 92 one only relies on the IP payload. The ICN related information is 93 used by network nodes and end nodes to support networking based on 94 content rather than (or better in addition to) end-point addresses. 95 Further information on the proposed solution can also be found in 96 [CONET11]. 98 In this memo we define a receiver driven transport protocol for CONET 99 (COntent NETwork) ICN, called ICTP - Information Centric Transport 100 Protocol. The transport protocol is able to provide a reliable 101 transfer of the content and to perform congestion control in TCP- 102 friendly way. A discussion about the definition of a transport 103 protocol for ICN can be found in [ICTP12]. 105 As shown in Figure 1, the CONET architecture proposed in [I-D.CONET] 106 foresees End-Nodes, Serving Nodes and CONET nodes. End-Nodes request 107 for content. Serving Nodes provide content. CONET nodes: i) forward 108 content requests from End-Nodes to Serving Nodes; ii) deliver content 109 from Serving Nodes to End-Nodes; iii) may cache content and therefore 110 provide it to End-Nodes without contacting the Serving Node. 112 requests for content 113 -------------------> 114 content is provided 115 <------------------- 116 +----+ +----+ +----+ 117 | | --| |------| | 118 +----+\ / +----+ +----+ 119 \ +----+ +----+ / 120 ----| |------| |/ 121 +----+ +----+ 122 End-Node legacy Intermediate Border Serving 123 IP router Node Node Node 124 | | 125 +---------CONET next hop----------->+ 127 Figure 1: CONET architecture 129 2. CONET Basics 130 In this section we recall the basic aspects of the CONET ICN 131 solution, as needed to introduce the proposed receiver driven 132 Information Centric Transport Protocol (ICTP). 134 The figure below shows the CONET protocol stack. CONET protocol is 135 divided in two sub-layers, whose data unit are respectively denoted 136 as "Carrier Packets" and "CONET Information Units". Two types of 137 CONET Information Units are currently defined ("Interests CIU" and 138 "Named Data CIU"). The CONET Information Unit Type field in the ICN 139 information header differentiates among the two types. A CONET 140 Information Unit (CIU) can be split into different Carrier Packets. 141 Each Carrier Packet is transported by an IP packet. 143 +--------+--------+--------+ \ 144 | CONET Information Units | | 145 +--------+--------+--------+ | 146 | 147 +--------+--------+--------+ |- CONET protocol 148 | Carrier Packets | | 149 +--------+--------+--------+ | 150 | 151 +--------+--------+--------+ / 152 | IP (opt. CONET IP option)| 153 +--------+--------+--------+ 155 Figure 2: CONET protocol layers 157 The generic structure of a Carrier Packet (CP) is reported hereafter: 159 +-------------------------+ 160 | CP Payload header | 161 +-------------------------+ 162 | CP Payload | 163 +-------------------------+ 164 | CP Path state | 165 +-------------------------+ 167 "Interest CIU" are used by End-Nodes to request for content. The 168 Interest CIUs contain the identifier of the content called ICN-ID and 169 transported within the ICN information header. Optionally, the ICN 170 information header explicitly carry a "Chunk Sequence Number" to 171 identify one of the chunk in which a content has been split. Another 172 possibility is that the chunk number is carried within the ICN-ID 173 itself. A Serving Node or a CONET node that had previously cached 174 the information can reply to the content request by sending a "Named- 175 data CIU". These Named-data CIU will also contain the ICN-ID in the 176 ICN information header. 178 The CP payload header contains the length of the CP Payload and 179 allows to identify the start of the CP Path state field. The use of 180 CP Path state field was explained in [I-D.CONET] and is out of scope 181 here. 183 The information contained in the CP Payload header is specific for 184 each CIU type. The information transported in the CP Payload header 185 can be used to implement the functionalities of a transport protocol, 186 providing a reliable transmission of content and performing 187 congestion control. In this document we define the CP Payload header 188 for Interest and Data CIUc using the ICTP protocol. 190 An end-node that wants to retrieve a content (or better a Chunk of a 191 content) issues an Interest CIU, the ICN-ID and (optionally) the 192 Chunk Sequence Number of the required Content are respectively 193 transported in the ICN Identifier (ICN-ID) field and in the CSN field 194 of the ICN information header. Assuming for simplicity that the 195 Interest CIU will fit into a single Carrier Packet, the Interest CIU 196 will be included in the Carrier Packet that in turn is inserted into 197 an IP packet. The ICTP comes into play because a Chunk of content 198 may need to be fragmented in more than one Carrier Packet, as the 199 chunk size can be much larger than the layer 2 MTU. For example with 200 a chunk size of 64 KB or 256 KB and an MTU of 1500 bytes, the chunks 201 need to be split in tens or hundreds of packets. In this case the 202 RDTP allows to specify in the request the specific segment of the 203 chunk that is required. 205 3. ICTP Data Structures 207 3.1. Interest CIU Payload Header 209 The structure of the interest CP payload header is reported 210 hereafter: 212 +-------------------------+ 213 |TTrrrrrPI| ..Left Edge...| 214 +-------------------------+ 215 | ...Right Edge... | 216 +-------------------------+ 218 Flags: 220 TT : Transport protocol type. It allows to define different 221 transport protocols. 0 indicates ICTP which is defined in this draft. 222 1-3 are reserved and can be used to indicate different transport 223 protocols. The rest of the bits in this field and in the following 224 bytes may have a different semantic depending on the transport 225 protocol, we are providing here only the defintion for TT=0 i.e. the 226 ICTP protocol. Therefore the number of transport protocols is NOT 227 limited to 4. 229 P : Prefetch flag - This flag indicates that this packet comes from a 230 receiver that asks to perform prefetch on the content chunks. 232 I : Ask Chunk Info flag - If this flag is set, the serving node is 233 requested to add chunk-related information to the data CIU payload, 234 particularly the chunk size. 236 Left edge/Right edge : These fields contain respectively the value of 237 first and the last byte of the requested chunk segment. The fields 238 are encoded with the EVLE (Efficient Variable Lenght Encoding) 239 mechanim described below 241 3.2. DATA CIU Payload Header 243 The structure of the data CP payload header is reported hereafter: 245 +-------------------------+ 246 |TTrFSSSS| ...Left Edge...| 247 +-------------------------+ 248 | ...Right Edge... | 249 +-------------------------+ 250 | (Optional) Chunk size | 251 +-------------------------+ 253 Flags: 255 TT : Transport protocol type. It allows to define different 256 transport protocols. 0 indicates ICTP which is defined in this draft. 257 1-3 are reserved and can be used to indicate different transport 258 protocols. The same considerations apply that have been reported 259 above for the TT subfield in the interest CIU payload header. 261 F : Final segment flag - If this bit is set to 1 this carrier packet 262 carries the last segment of a chunk. 264 SSSS : Chunk size flag - This flag describes the size of a chunk as 265 follows: 267 0 : unspecified (it may have been already indicated 268 in a previous data) 269 1 : the chunk size is trasnported in the optional 270 Chunk size field, encoded with the EVLE variable length 271 encoding described below 272 2-16 : let n be the value from 2 to 16, it can represent 273 14 different chunk sizes from 2KBytes to 8Mbyte 274 with the following relation: 275 chunk size = 2 ^ (9+n) 277 Left edge/Right edge : These fields contains respectively the value 278 of first and the last byte of the transported chunk segment. The 279 fields are encoded with EVLE variable length encoding described 280 below. These fields carry the actual value of the segment 281 transported that may differ from the request. 283 3.3. EVLE Efficient Variable Length Encoding 285 Some of the fields described above are encoded using a variable 286 lenght encoding that we denote as "Efficient Variable Lenght 287 Encoding". The same encoding is used for the Chunk Sequence Number 288 (CSN) field in the ICN information header, as described in 289 [I-D.CONET]. To help the reader, we report the definition of the 290 encoding hereafter. An EVLE field is represented with a variable 291 number of bytes. An initial bit pattern determines the length of the 292 EVLE field. 294 1 byte EVLE (7 bits range) 295 +--------+ 296 |0 | 297 +--------+ 299 2 bytes EVLE (15 bit range) 300 +--------+--------+ 301 |10 | 302 +--------+--------+ 304 3 bytes EVLE (21 bit range) 305 +--------+--------+--------+ 306 |110 | | | 307 +--------+--------+--------+ 309 4 bytes EVLE (28 bit range) 310 +--------+--------+--------+--------+ 311 |1110 | | | | 312 +--------+--------+--------+--------+ 314 5 bytes EVLE (32 bit range) 315 +--------+--------+--------+--------+ 316 |11110000| | | | 317 +--------+--------+--------+--------+ 318 | | 319 +--------+ 321 6 bytes EVLE (40 bit range) 322 +--------+--------+--------+--------+ 323 |11110001| | | | 324 +--------+--------+--------+--------+ 325 | | | 326 +--------+--------+ 328 As explained in in [I-D.CONET], binary patterns from 11110010 to 329 11111111 are reserved and could be used to extend the EVLE range if 330 needed. With the above definion the maximum value is 2^40, roughly 1 331 Tera. 333 4. ICTP mechanisms 335 The transport protocol described in this draft mimics the TPC 336 mechanisms described in [RFC2581], with the required adaptations for 337 a receiver driven approach. In fact, while in TCP the sender sends 338 data segment and implements retransmissions and congestion control 339 based on the reception of ACKs, in ICN based content download the 340 receiver asks for content sending the Interests and implements re- 341 sending of Interests and congestion control based on the reception of 342 Data. 344 4.1. Congestion control mechanisms 346 4.1.1. Fast recovery and fast retransmit 348 The receiver bases its flow control on the received data CP. The out 349 of sequence recognition is based on the expected chunk number and 350 segment bytes. When three out-of-sequence data CP are received the 351 slow start threshold (ssthresh, see [RFC2581]) is set to half the 352 window. Then the window is set to ssthresh plus the 3 data carrier 353 packet already received and the interest for the missing segment is 354 retransmitted. 356 4.1.2. Slow start and congestion avoidance 358 To manage the increase of congestion window slow start and congestion 359 avoidance mechanism are performed. During slow start, (e.g. the 360 beginning of the connection), the congestion window increases of an 361 amount equal to the received data CP. This corresponds to an 362 "exponential" growth of the window. During congestion avoidance, the 363 growth of the window is aproximately "linear" with time. Let us 364 define a "segment" as the portion of content transported in a data 365 CP. We define the congestion window cwnd in segments. During slow 366 start cwnd = cwnd + 1 for each received data CP. During congestion 367 avoidance cwnd = cwnd + 1/cwnd for each received data CP. 369 4.2. ICTP specific mechanisms 371 4.2.1. Prefetch option 373 In a ICN based network, we can have applications separately 374 requesting the download of each chunk of content. In our ICTP 375 approach this means that we can only request the segments of a given 376 chunk after that we have received the request for the chunk coming 377 from the application. The application may implement retransmission 378 and congestion control, therefore the ICTP could receive requests for 379 more than a chunk of the same content in parallel. Anyway the 380 interaction between the congestion control performed at application 381 level and the congestion control performed at ICTP level could prove 382 inefficient. Therefore we believe that the API offered to the 383 application should allow the application to request for a whole 384 content (or for the content starting from a given chunk number). 385 Then the ICTP protocol can handle the retrieval of all the (rest of) 386 the content. Therefore the ICTP protocol offers also a "prefetch 387 option". Whit the prefetch option active, if the congestion window 388 has space left, the mechanism allow to issue requests for segments of 389 next expected chunks, without waiting for an explicit request from 390 application level. 392 4.2.2. Request chunk information 394 When the transmission start, the receiver must issue a request for at 395 least the chunk size. Receiver should set the flags in carrier 396 packet accordingly to Section 3.1. The data ciu requested will carry 397 at least the chunk size, receiver should use this information to 398 create data structure best suited for the chunk size. 400 5. Performance Considerations 401 A goal of the ICTP transport protocol is to compete fairly with TCP. 402 This allows a fair sharing of reources when TCP flows and ICN flows 403 compete over network links. 405 6. Acknowledgments 407 We acknowledge the financial support by the EU in the context of the 408 CONVERGENCE research project. 410 7. IANA Considerations 412 This document requires the allocation of one IP protocol number by 413 the IANA. 415 This document requires the allocation of one IP option by the IANA if 416 the solution of using IP options is adopted 418 This document requires that IANA will maintain the registry of CONET 419 namespaces. 421 8. Security Considerations 423 Security considerations to be provided 425 9. References 427 9.1. Normative References 429 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 430 1981. 432 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 433 (IPv6) Specification", RFC 2460, December 1998. 435 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 436 June 1999. 438 9.2. Informative References 440 [CONET11] A. Detti, et al., ., "CONET: A Content Centric Inter- 441 Networking Architecture", ACM SIGCOMM Workshop on 442 Information-Centric Networking (ICN-2011), Toronto, Canada 443 , August 2011. 445 [I-D.CONET] 446 Detti, A., Salsano, S., and N. Blefari-Melazzi, "IP 447 protocol suite extensions to support CONET Information 448 Centric Networking", draft-detti-conet-ip-option-05 (work 449 in progress), June 2013. 451 [ICTP12] S. Salsano, et al., ., "Transport-layer issues in 452 Information Centric Networks", ACM SIGCOMM Workshop on 453 Information-Centric Networking (ICN-2012), Helsinki, 454 Finland , August 2012. 456 [Jacobson09] 457 V. Jacobson, et al., ., "Networking named content", Proc. 458 of ACM CoNEXT 2009 , 2009. 460 [Koponen07] 461 T. Koponen et al., ., "A data-oriented (and beyond) 462 network architecture", Proc. of ACM SIGCOMM 2007 , 2007. 464 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 465 Control", RFC 2581, April 1999. 467 Authors' Addresses 469 Stefano Salsano 470 Univ. of Rome "Tor Vergata" 471 Via del Politecnico, 1 472 Rome 00133 473 Italy 475 Email: stefano.salsano@uniroma2.it 477 Andrea Detti 478 Univ. of Rome "Tor Vergata" 479 Via del Politecnico, 1 480 Rome 00133 481 Italy 483 Email: andrea.detti@uniroma2.it 485 Nicola Blefari-Melazzi 486 Univ. of Rome "Tor Vergata" 487 Via del Politecnico, 1 488 Rome 00133 489 Italy 491 Email: blefari@uniroma2.it 492 Matteo Cancellieri 493 Univ. of Rome "Tor Vergata" 494 Via del Politecnico, 1 495 Rome 00133 496 Italy 498 Email: matteo.cancellieri@gmail.com