idnits 2.17.1 draft-rfced-exp-beauchamp-00.txt: 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 (2024-04-23) 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) 2024 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 124 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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.) ** There are 184 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 169 has weird spacing: '...pe used simpl...' == Line 831 has weird spacing: '...elivery to a ...' -- 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.) -- The document date (December 1997) is 9626 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 896 looks like a reference -- Missing reference section? '2' on line 900 looks like a reference -- Missing reference section? '3' on line 902 looks like a reference -- Missing reference section? '4' on line 906 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT 2 Network Working Group J. Beauchamp 4 Raytheon E-Systems 6 December 1997 8 The Coherent File Transport Protocol 9 11 Status of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Distribution of this document is unlimited. 33 Introduction: 35 The Coherent File Transport Protocol is an adaptation and extension to 37 the Coherent File Distribution Protocol described in RFC 1235 [1]. The 39 adaptations and extensions are designed to optimize the movement of 41 information over a highly asymmetric satellite broadcast channel with a 43 low bandwidth and a potentially long delay return path to the server 45 source. 47 This protocol is designed to exploit the broadcast capabilities of a 49 satellite data service with the capability of a high bandwidth (10s of 51 Mb/s) and to provide reliable delivery to a large number of users. The 53 protocol is designed to operate in a noisy environment (Bit Error Rate of 55 10-6) and makes few assumptions about the receiving locations with 57 respect to their availability or operating environment. Recipients are 59 expected to have a return path to the broadcast source to positively 61 acknowledge receipt of a unit of information (referred to here as a 63 file). The delay of the return path from recipients to source is 65 expected to be variable and potentially long. The protocol allows for 67 instances in which the return path may be totally absent (see Protocol 69 Extensions). 71 The protocol differs from a traditional client-server model in that the 73 transmission source is free to broadcast either unanticipated or 75 unsolicited information to one or more recipients, Each active recipient 77 must examine each received file and packet and decide if the file or 79 packet is of interest. In order to preserve this differentiation, this 81 memo refers to recipients and sources rather than clients and servers. 83 In broad application, CFTP is anticipated to be most useful as a protocol 85 to tunnel other protocols over a satellite broadcast network reliably. 87 However, the protocol has advantages in other broadcast environments in 89 that it requires very little setup to initiate a transfer and the 91 acknowledgment mechanism consumes a minimum amount of bandwidth by each 93 recipient. Simple modifications to the protocol as described here allow 95 a unique combination of services to users who can respond through 97 acknowledgments and to users who cannot or will not respond to broadcast 99 data but who wish to receive information. 101 Overview: 103 As in RFC-1235, our implementation uses UDP [2] as the transport protocol 105 but this is not a requirement of the protocol. Any broadcast datagram 107 protocol could be employed. The satellite broadcast implementation 109 assumes that there is only a single, unidirectional link (the satellite 111 channel) between the source and recipient and that acknowledgment 113 information from the recipient to the source is carried on a separate and 115 independent media. 117 In the general case, we assume that a file (which is any form of 119 delimited traffic) to be transmitted is sent to the satellite source by 121 an outside agent by any convenient protocol. We also assume that this 123 file contains information about the intended recipients so that the file 125 can be properly addressed to the destination. For example, a multicast 127 group IP address [3] could be used by the source and this multicast group 129 IP address would then become the address used by CFTP. 131 While it is outside of the scope of the protocol discussed here, there is 133 an issue of delivery acknowledgment between the external originating 135 agent and the CFTP recipient. CFTP is a "best effort" delivery protocol 137 in that the protocol will reliably deliver a file to any and all 139 recipients who are listening to the satellite broadcast at the time the 141 file is transmitted and respond with acknowledgements. However, the 143 action of the protocol is not driven by delivery to specific recipients 145 who may or may not be listening at the moment of transmission. Although 147 CFTP does not maintain a list of active recipients, the protocol is 149 capable of identifying all recipients who have successfully received a 151 specific file. This information can be sent to the originating external 153 agent. 155 The protocol begins with the receipt of a file from an external agent. 157 CFTP assigns a unique number to this file in the form of a 32 bit value 159 referred to as the "ticket number". This 32 bit value is the binding 161 entity that allows both the recipient and source to refer to the same 163 file. This ticket number is combined with file size, file name, block 165 size (information content size of each packet associated with the file), 167 and user information to form a packet that is referred to as a "ticket". 169 The ticket packet is queued for transmission. Our prototype used simple 171 FIFO queuing within priority classes but any other queuing discipline can 173 be applied. When the ticket packet is taken from the queue, it is 175 broadcast over the channel. If the channel is noisy, this ticket packet 177 broadcast can be repeated one or more times to improve the probability of 179 receipt of the ticket by all intended recipients. As soon as the ticket 181 packet transmission is complete, it is immediately followed by the 183 broadcast of the file in the form of packets that contain the ticket 185 number, the packet sequence number (reset to 0 at the beginning of each 187 new file), and the packet data. When the file transmission is complete, 189 the source is free to select the next queued item (either a new ticket 191 packet and file or retransmission of previously NAKed packets)and begin 193 broadcasting this new item. 195 Each recipient listens for the ticket on a preestablished UDP port and 197 decides if the ticket is of interest. If a specific recipient decides to 199 receive the file associated with the ticket, it immediately allocates 201 space to receive the file and marks all packets as not received. As 202 packets are correctly received, they are placed in their proper location 204 as determined by the packet sequence number and marked as received. 206 When the last packet of a transmission is received or the recipient notes 208 a change in ticket numbers in the received stream or the expiration of a 210 receive file timeout, the recipient notes all of the packets not received 212 by packet sequence number and composes a list of these packet sequence 214 numbers. This list of packet sequence numbers becomes a selective NAK 216 for this recipient and is transmitted back to a preestablished port at 218 the CFTP source using any convenient protocol; our prototype 220 implementation uses standard TCP for this return. The recipient includes 222 the ticket identifier so that the source can unambiguously identify the 224 file. A receipt containing a ticket number with no packets is taken by 226 the source as a positive acknowledgment of receipt of the file. 228 At the source, these NAK messages are collected and a list of all packets 230 not received by one or more recipients is created. When the source 232 decides that the last of these NAK messages has been received, it queues 234 the ticket and list of packets to resend. When this ticket arrives at 236 the top of the queue, the packets contained in the consolidated list of 238 NAKed packets is sent using the standard data transmission packet 240 described below; the ticket is not resent. 242 As each recipient completely receives the file, it simply ignores any 244 other traffic associated with the file. This means that different 246 recipients can complete reception of a file at different times depending 248 upon their local environment. 250 Two additional conditions are worth discussion in this overview. First, 252 the effect of a selective NAK that arrives after the next transmission 254 has been scheduled and second, the arrival of a selective NAK for a 256 ticket that has been closed. Other than the potential loss of channel 258 efficiency, the effect of a late arriving NAK transmission causes few 260 problems. The protocol notes the packets received in error and 262 associates these packets with the next scheduled transmission. The 264 problem, of course, is that the late NAK may include packets that are 266 already scheduled for transmission and repeating them simply wastes 268 bandwidth. In the case that the source has closed a ticket, the source 270 simply drops the unexpected request for information; the recipient must 272 time-out the transfer and dispose of the partially received file. 274 Protocol Specification: 276 Initiation (not strictly a part of CFTP): 278 An external agent presents a delimited item of traffic (file) to a well 280 known port to the CFTP service agent. For our prototype implementation, 282 this service agent terminates the protocol with the external agent. At 284 this point, the external agent can only know that the file was delivered 286 to the CFTP source and the CFTP source will make a best effort delivery 288 to the CFTP recipient(s); the CFTP source will deliver reliably to those 290 recipients who respond. 292 With the file in hand, the CFTP source builds a ticket as shown in figure 294 1. The ticket number appears as the first data item. The checksum is 296 used to test the integrity of all information in the packet past the 298 filler. For this initial transmission, the type field is filled with 'F' 299 indicating the first transmission of this file and that the ticket should 301 be broadcast. At the source, we have included a priority field that is 303 used to determine the transmit queue ordering. Our prototype 305 implementation uses this format as an internal control structure and 307 queues tickets (using this internal control structure) first-in-first-out 309 within a priority class. The value of block size is the amount of file 311 data that will be included in each UDP packet transmitted. With a 16 bit 313 value, we can accommodate UDP packets up to 64k Bytes. A total of 255 315 bytes is allocated to the file name. The value of file name is a null- 317 terminated ASCII string. The remainder of the packet is allocated to 319 user data. We anticipate that this user data area will incorporate 321 metadata that will be used by recipients to decide if this file is to be 323 received. 325 First Transmission: 327 At the moment the ticket is selected for transmission by the source, the 329 priority field is replaced by the total block count for this file and the 331 type field is set to 'T'(fig. 2). This allows recipients to recognize 333 that this is a ticket packet and to create their received list as well as 335 allowing them to allocate space to receive the file that will follow 337 immediately. 339 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | "ticket" | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | "chksum" | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | type = 'F' | filler | user data length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | priority | blksize | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 / / 363 \ Filename, null-terminated, up to 255 octets \ 365 / / 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 / / 371 \ user data area up to (blksize - 255) octets \ 373 / / 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Fig. 1: Source Ticket Packet (internal). 379 0 1 2 3 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | "ticket" | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | "chksum" | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | type = 'T' | filler | user data length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | block count | blksize | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 / / 403 \ Filename, null-terminated, up to 255 octets \ 405 / / 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 / / 411 \ user data area up to (blksize - 255) octets \ 413 / / 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Fig. 2: Source Ticket Packet transmitted. 419 While it is not a requirement of the protocol, our prototype 421 implementation broadcasts the ticket multiple times. This rebroadcast 423 increases the likelihood that all recipients will hear the ticket. In 425 general, we cannot know the status of all potential recipients nor their 427 channel performance. Should the recipient see more than one of multiply 429 broadcast copies of the ticket, the recipient simply ignores the 431 duplicates. 433 As soon as the ticket is transmitted, the source transmits all of the 435 packets for the file. The CFTP data packet is shown in fig. 3. The last 437 packet of a file may not occupy a complete blksize and it is up to the 439 recipient to note that this last packet is short. The type field is set 441 to 'B' and, except for the last packet, the EOT field is set to 0. The 443 EOT field is not absolutely essential for the first transmission, the 445 recipient could easily compare the current block number with the block 447 count contained in the ticket. However, the EOT field is important for 449 the partial transmissions to be discussed later since it identifies the 451 last data to be transmitted under this ticket at this time and the last 453 block to be transmitted may not be the last block in a file if the last 455 block was not requested by any recipient. 457 0 1 2 3 459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | "ticket" | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | "chksum" | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | type = 'B' | EOT | block number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 / / 477 \ Filedata, up to blksiz octets \ 479 / / 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Fig. 3: Data Packet. 485 Recipient Protocol: 487 A state diagram for the recipient operations is shown in figure 4. Once 489 a recipient hears a ticket and decides to receive the file, the recipient 491 adds the ticket identifier to the list of active tickets and listens for 493 broadcast packets on the CFTP/UDP port that have a ticket number that 495 matches one of the active tickets being received. If the data packet 497 contains a packet that has not been previously received, the recipient 499 adds the data into the received file and marks the block as being 501 received. 503 +-----------+ 505 | Recipient | 507 | start | 509 | | 511 | receive | 513 | ticket | 515 +-----------+ 517 | 519 received packet | receive packet 521 .-----------------------. | 523 | V V 525 +---------+ +---------+ 527 | INCMPLT | | | 529 | | timeout 1 | receive | <---. 531 .-| send |<------------| | | received packet 533 | | PARREQ | or | message | ----' 535 | | |non received | | 537 | +---------+ packets +---------+ 539 | ^ | | 541 | '---' |finished 543 | timeout 2 | 545 | | 547 | timeout 3 or | 549 | retry limit V 551 | +-----------+ +---------+ 553 .-->| ABORT | | END | 555 +-----------+ +---------+ 557 Fig. 4: Recipient State Transition Diagram 559 (figure adapted from RFC 1235) 560 If the packet EOT flag is non-zero, the recipient scans the list of 562 received blocks associated with the ticket and notes all of the blocks 564 that it has not received. This list of non-received blocks is composed 566 into a partial request message packets and sent to the source, the format 568 for this message packet is shown in figure 5. As noted in the overview, 570 the recipient can use any convenient protocol to return this packet to 572 the source however, we anticipate the use of a protocol such as 574 transaction TCP [4]. The source is assumed to be at a well-known IP 576 address or extracted from the IP packet and the recipient directs this 578 message to the CFTP port at the source address. In our prototype 580 implementation, if there are more unreceived blocks than can fit within a 582 single message packet, the recipient holds these additional message 584 packets until the next transmission of the file. This is not a 586 requirement of the protocol, the recipient is free to send multiple NAK 588 packets through the return path by whatever mechanisms are permitted in 590 the return protocol. 592 0 1 2 3 594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | "ticket" | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | "chksum" | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | blkcnt | block #1 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | block #2 | block #3 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | block #4 | block #5 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 / / 620 \ block numbers, up to blksiz octets \ 622 / / 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Fig. 5: Partial Request Message. 628 If the recipient finds no blocks to request from the source, it marks the 630 file as received and removes the ticket from its list of active tickets. 632 Note that the recipient sends a return message indicating there are no 634 additional packets required. This is interpreted by the source as a 636 positive acknowledgment of receipt of the file. Since the recipient 638 removes the ticket from its list of active tickets, any packets received 640 for this ticket will be simply dropped. 642 If a recipient does not receive the last packet of a message then the 644 recipient must transition to the INCMPLT state. In a situation in which 646 there is a continuous flow of traffic, the recipient will notice the 648 change in ticket number without having received the last packet of the 650 previous transmission. In a lightly loaded channel, some significant 652 period of time could elapse before another ticket arrives and thus we use 654 timeout 1 to force the transition to the INCMPLT state. 656 It is possible that a partial request message could be lost in the return 658 path or that the recipient has missed a retransmission of a small number 660 of packets from the source. To handle this condition, the recipient 662 periodically retransmits the partial request to the source as set by 664 timeout 2. 666 We use timeout 3 to abort partially received messages. If we have not 668 heard a reply from the source after a long time, the recipient assumes 670 that both the message and ticket have been lost and the recipient deletes 672 all partially received blocks from the message and then removes the 674 ticket from the list of active tickets. 676 Finally, it is possible for a recipient to be receiving small portions of 678 a message with each retransmission. Even though reception progress is 680 being made by an individual recipient, the network resources required for 682 this individual may be excessive. We control this through a retry limit. 684 The retry limit is associated with the recipient rather than the source 686 in order to be able to offer more persistent delivery to recipients who 688 are special. 690 Server Protocol: 692 A state diagram of the server protocol is shown in figure 6. Initially, 694 the source is idle; it receives a file from an external agent and builds 696 a ticket. The ticket is transmitted followed by the transmission of the 698 entire file. When the message is completely transmitted, the source 700 places the ticket in the wait-for-ack state. While the ticket is in this 702 state, the source receives the partial requests from recipients and 704 builds a list of the blocks to retransmit. In general, the source cannot 706 assume that it knows the total number of recipients that might respond 708 and therefore removes the ticket from this state after a time-out. Upon 710 exiting this state, the source notes the total number of blocks requiring 712 retransmission. If this total number of blocks is zero, the source 714 assumes that all interested recipients have correctly received the file 716 and removes the ticket and file from the active list. If the number of 718 blocks requiring retransmission is not zero, the source queues the 720 (internal) ticket for retransmission along with the list of blocks to be 722 retransmitted. When the retransmission of the list of blocks is 724 complete, the source again waits for responses from the recipients. 726 +--------+ +---------+ +----------+ +---+ 728 | Source | extrn | send | | wait for | no | d | 730 | idle |------->| ticket |----->| ack |--------->| o | 732 +--------+ request| and | | packets | requests | n | 734 | file | .>| | | e | 736 +---------+ | +----------+ +---+ 738 | | 740 time-out | V 742 | +----------+ 744 | | send | 746 '-| requested| 748 | blocks | 750 +----------+ 752 Fig. 6: Source State Transition Diagram 753 It is possible that there is no recipient that decides to receive a 755 particular file. This is detected by CFTP by noting that there are no 757 requests for retransmission after the wait for ack timeout. This 759 approach simplifies the protocol state machine to transition to the done 761 state in any instance in which there are no requests for packets from a 763 message. 765 Tunable Parameters: 767 Packet size: In a satellite broadcast application, there is considerable 769 flexibility in setting packet sizes. Shorter packets are individually 771 less likely to be errored by channel noise but reduce user data bandwidth 773 through protocol overhead. Shorter packets also potentially increase the 775 amount of recipient bandwidth to report non-received packets. Longer 777 packets are individually more likely to be errored by channel noise and 779 can significantly reduce user data bandwidth if the channel is noisy. 781 Our analysis suggests that a packet length between 2,000 and 2,500 octets 783 is a reasonable value in channels that are as bad as 1x10-7. 785 Time-outs: Setting appropriate time-out values in the protocol are 787 somewhat implementation-dependent and certainly dependent upon the 789 anticipated loading within the channel. Our prototype implementation has 791 emphasized speed of service and thus has set several time-out values 793 associated with acknowledgment time-outs to minimum values. The most 795 critical of these is in the source where the source is waiting for 797 acknowledgment. We picked a value of 750 msec with this time-out 799 beginning when the last packet of a file has been sent. This value 801 allows 250 msec for transport over a satellite and 500 msec for 803 acknowledgment returns. 805 ACK Implosion: 807 As with any reliable multicast or broadcast protocol, CFTP is subject to 809 a potentially large number of acknowledgments in a large recipient 811 population. This is easily controlled by incorporating intermediate ACK 813 collection processors who forward a smaller number of acknowledgments to 815 the source. Use of such ACK concentrators involves directing recipients 817 to address retransmission requests to a concentrator. The source is not 819 concerned about the address of the device providing the retransmission 821 request. 823 Protocol Extensions: 825 The loose relationship between a CFTP source and CFTP recipient creates 827 opportunities for some unconventional operations. First, we define a 829 probabilistic delivery extension to the protocol in which we offer a 831 "good chance" delivery to a recipient who cannot or will not respond. 833 Second, by incorporating metadata that describes either the intended 835 audience of a file or the content of the file (or both), we can have a 837 file delivery model that includes content as well as address. 839 Probabilistic Delivery: 841 Probabilistic delivery uses one or more retransmissions to increase the 843 likelihood that a recipient correctly receives a file given we have no 845 feedback from the recipient. For example, if we have a file consisting 847 of 400 packets of 2,500 octets (a 1 Mbytes file), the likelihood of this 848 message being received correctly in a channel with a gaussian bit error 850 rate (BER) of 1*10-7 is about 44%. If each packet is transmitted twice, 852 the likelihood of correctly receiving this message rises to about 99.8% 854 and with 3 transmissions, this probability is greater than 99.99%. 856 CFTP is modified to operate in this mode by simple changes in the source. 858 In the internal data structures maintained by the source, a field is 860 added that indicates the number of transmissions of each packet during 862 the initial broadcast of the file. Recipients receive these multiple 864 transmissions and simply accept the first correctly received packet, the 866 normal protocol operations at the recipients drops duplicates. After 868 this initial broadcast, the source continues the protocol as described 870 above. Any retransmissions caused by recipient requests are only 872 broadcast once. 874 Content Delivery: 876 Investigations into metadata are relatively new but are very promising as 878 a tool to summarize a document. Standards for metadata are only 880 beginning to evolve and any attempt to specify a specific method here is 882 likely to be incompatible with the future. We have reserved an area 884 inside the ticket to include metadata but in this instance, the metadata 886 field is included as a "vendor-specific area" as done in bootp. Our 888 model for metadata within the ticket follows an entity-attribute model; 890 we are following the activities of the X3L8 committee as they develop 892 standards for metadata. 894 References: 896 [1] Ioannidis, J. and Maguire, G., "The Coherent File Distribution 898 Protocol", RFC 1235, June 1991. 900 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 902 [3] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 904 1989. 906 [4] Jacobson, V, Braden, R., Borman, D., "TCP Extensions for High 908 Performance", RFC1323, May 1992. 910 Security Considerations: 912 Security issues are not discussed in this document. 914 Author's Address 916 Jere Beauchamp 918 Raytheon E-Systems 920 P.O. Box 12248 922 St. Petersburg, FL 33733 924 EMail: jnba@eci-esyst.com Phone: (813) 302-2397 926 INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT