idnits 2.17.1 draft-whetten-rmtp-ii-app-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-26) 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 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. ** 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 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 an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references (Rizzo97], [Rizzo97], [NBT97], [NB96], [NB96,NBT97,, [WMK94]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 8, 1998) is 9515 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? 'WMK94' on line 124 looks like a reference -- Missing reference section? 'NB96' on line 1248 looks like a reference -- Missing reference section? 'NBT97' on line 1253 looks like a reference -- Missing reference section? 'Rizzo97' on line 1257 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: RMTP-II Specification B. Whetten, M. Basavaiah 3 draft-whetten-rmtp-ii-app-00.txt GlobalCast Communications, Inc. 4 Expires: Six months S. Paul 5 Lucent Technologies, Bell Labs 6 T. Montgomery 7 West Virginia University 8 N. Rastogi, J. Conlan, T. Yeh 9 GlobalCast Communications, Inc. 10 April 8, 1998 12 THE RMTP-II PROTOCOL APPENDICES 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is not appropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 31 (US West Coast). 33 Abstract 35 These appendices furnish supplementary information for the RMTP-II 36 protocol draft. The appendices contain information on design 37 rationale, congestion control algorithms, SNMP MIBs, forward error 38 correction, time bounded reliability, and work in progress 40 APPENDIX A - DESIGN RATIONALE 42 It is widely recognized that no single reliable multicast protocol 43 can meet the needs of all applications over all network types. 44 RMTP-II targets a specific subset of application and network types. 46 Targeted Network Types 48 RMTP-II is designed to work over a controlled network, which 49 typically has a single administrative domain. These networks have 50 the fewest barriers to IP multicast and the greatest need for 51 reliable multicast services. 53 There is no current standard for bridging IP multicast over multiple 54 administrative domains and heterogeneous routing protocols, although 55 work is continuing in this area. In addition, internet service 56 providers have concerns about peering and settlement for IP multicast 57 traffic which spans multiple domains. These issues are delaying the 58 deployment of widespread native IP multicast in the Internet. In 59 contrast, a number of private companies, satellite operators, and 60 ISPs have turned on, or are in the process of turning on, IP 61 multicast for use strictly within their networks. 63 In a conrolled intranet environment, a single network management 64 organization typically controls each of the networks in which RMTP-II 65 will be deployed. In order to promote the adoption of RMTP-II the 66 following are required: 68 - Network managers require tools for the monitoring and control of the 69 reliable multicast traffic. 71 - Network managers can provide manual configuration of the protocol, 72 although requirements for this should be minimized. 74 - Network managers can provide additional control over network 75 congestion in addition to automatic end-to-end congestion control. 77 - Network managers can have direct control over multicast senders. 79 RMTP-II takes these requirements into account by providing the 80 following features: 82 - RMTP-II provides SNMP management of the control nodes. 84 - RMTP-II segments node operations into trusted nodes (control nodes), 85 and user nodes (sender and receiver nodes). 87 - RMTP-II allows manual or automatic tree configuration. 89 - RMTP-II provides the top node as a centralized point through which 90 network managers control the rate parameters and congestion 91 algorithms of the senders. 93 - RMTP-II provides access control of multicast senders. 95 While the majority of controlled networks are symmetrical and support 96 many-to-many multicast, a significant percentage are asymmetrical and 97 support few-to-many multicast. RMTP-II takes this into account by 98 not requiring any many-to-many multicast services, and by dividing 99 the communication paths of the protocol into two pieces - the data 100 channel and the control channel. The use of a separately defined 101 data channel, which is not assumed to overlap with the control 102 channel, allows RMTP-II to support asymmetrical networks, such as a 103 one way satellite data feed with a terrestrial return path, and ADSL. 105 A number of extensions to IP multicast, such as subtree multicast, 106 ACK accumulation, and PGM, have been proposed which can run in the 107 routers. This would make tree based reliable multicast protocols 108 easier to configure and to scale more readily. To date, none of 109 these mechanisms have been standardized or released by a major 110 commercial vendor. RMTP-II is designed with these mechanisms, 111 especially subtree multicast, in mind. However, since the current 112 goal of RMTP-II is to provide an immediate, graceful deployment path, 113 these features will only be supported as options. 115 Targeted Application Types 117 Multicast applications can be divided into two classes, few-to-many 118 and many-to-many. Many-to-many applications include server 119 replication, multi-user games, small group conferencing, and computer 120 supported collaborative work. These applications typically treat all 121 members in a group as peers, require special semantics such as total 122 ordering of messages from multiple senders, and rarely require 123 scalability beyond 100 receivers. Other protocols, such as RMP 124 [WMK94], have been designed to support these many-many applications. 126 RMTP-II focuses on few-to-many applications, such as multicast file 127 transfer, electronic software distribution, real time news and 128 financial distribution, "push" applications, audio/video/data 129 broadcasts, distance learning, and some types of server replication. 130 These applications typically require at most 50 simultaneous senders, 131 10,000 or more receivers, have different roles for senders and 132 receivers, and do not require total ordering of messages between 133 senders. These applications may require strong guarantees on 134 delivery, streaming of data in real time, or support for synchronous 135 streaming. RMTP-II is designed to meet all of these requirements. 137 RMTP-II provides a strong, but fully distributed membership protocol 138 which supports scaling to 10,000 or more simultaneous receivers while 139 providing strong guarantees on message delivery. RMTP-II is a 140 streaming protocol and provides support for real time applications. 142 RMTP-II meets the requirement of synchronous streaming applications 143 with a new quality of service level called Time Bounded Reliability. 144 Time Bounded Reliability restricts recovery of packets to a limited 145 time interval. This keeps dropped packets from blocking the rest of 146 a synchronous data stream and prevents a failed receiver from 147 affecting other receivers. 149 RMTP-II takes the application semantics into account by dividing the 150 nodes' roles into senders, receivers, and control nodes. 152 Other Design Considerations 154 In addition to the requirements imposed by the targeted network and 155 application types, RMTP-II takes into account the following factors 156 and design goals: 158 - ACK and NACK implosion must be prevented. 160 - Control traffic, retransmission traffic, and retransmission latency 161 must be minimized. 163 - End-to-end congestion control algorithms must be strongly supported 164 as they become mature. 166 - Simplicity of design is required for ease of use and development. 168 - Extensibility must be supported for future development. 170 APPENDIX B - CONGESTION CONTROL ALGORITHMS 172 Work in progress. 174 APPENDIX C - SNMP MIBS FOR RMTP-II 176 This appendix defines the SNMP MIB for the RMTP-II protocol and its 177 entities. The MIBS are grouped according to the functionality of the 178 RMTP-II nodes. 180 RMTP DEFINITIONS ::= BEGIN 181 IMPORTS 182 enterprises, Counter, Gauge, IpAddress 183 FROM RFC1155-SMI 184 OBJECT-TYPE 185 FROM RFC-1212 186 TRAP-TYPE 187 FROM RFC-1215 188 PhysAddress 189 FROM RFC1213-MIB; 191 internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } 192 directory OBJECT IDENTIFIER ::= { internet 1 } 193 mgmt OBJECT IDENTIFIER ::= { internet 2 } 194 experimental OBJECT IDENTIFIER ::= { internet 3 } 195 private OBJECT IDENTIFIER ::= { internet 4 } 196 enterprises OBJECT IDENTIFIER ::= { private 1 } 198 globalcast OBJECT IDENTIFIER ::= { enterprises 2751 } 199 rmtp OBJECT IDENTIFIER ::= { globalcast 1 } 200 ln OBJECT IDENTIFIER ::= { rmtp 1 } 201 sd OBJECT IDENTIFIER ::= { rmtp 2 } 202 ag OBJECT IDENTIFIER ::= { rmtp 3 } 203 dr OBJECT IDENTIFIER ::= { rmtp 4 } 204 tn OBJECT IDENTIFIER ::= { rmtp 5 } 205 common OBJECT IDENTIFIER ::= { rmtp 6 } 207 ------------------ 208 -- Group common -- 209 ------------------ 211 inPkts OBJECT-TYPE 212 SYNTAX Counter 213 ACCESS read-only 214 STATUS mandatory 215 DESCRIPTION "The number of packets received, unicast and multicast" 216 ::= {common 1} 218 outPkts OBJECT-TYPE 219 SYNTAX Counter 220 ACCESS read-only 221 STATUS mandatory 222 DESCRIPTION "The number of packets sent" 223 ::= {common 2} 225 inMcastPkts OBJECT-TYPE 226 SYNTAX Counter 227 ACCESS read-only 228 STATUS mandatory 229 DESCRIPTION "The number of multicast packets received" 230 ::= {common 3} 232 outMcastPkts OBJECT-TYPE 233 SYNTAX Counter 234 ACCESS read-only 235 STATUS mandatory 236 DESCRIPTION "The number of multicast packets sent" 237 ::= {common 4} 239 -------------- 240 -- Group ln -- 241 -------------- 243 lnParentAddress OBJECT-TYPE 244 SYNTAX IpAddress 245 ACCESS read-only 246 STATUS mandatory 247 DESCRIPTION "IP Address of the parent node in the RMTP tree" 248 ::= {ln 1} 250 lnParentPort OBJECT-TYPE 251 SYNTAX INTEGER 252 ACCESS read-only 253 STATUS mandatory 254 DESCRIPTION "UDP port of the parent node in the RMTP tree" 255 ::= {ln 2} 257 lnHbPkts OBJECT-TYPE 258 SYNTAX Counter 259 ACCESS read-only 260 STATUS mandatory 261 DESCRIPTION "The number of Heartbeat packets received" 262 ::= {ln 3} 264 lnNumRejoin OBJECT-TYPE 265 SYNTAX Counter 266 ACCESS read-only 267 STATUS mandatory 268 DESCRIPTION "The number of Rejoin requests made internally" 269 ::= {ln 4} 271 lnStreamTable OBJECT-TYPE 272 SYNTAX SEQUENCE OF StreamEntry 273 ACCESS not-accessible 274 STATUS mandatory 275 DESCRIPTION "The Stream table - basic information." 276 ::= {ln 5 } 278 lnStreamEntry OBJECT-TYPE 279 SYNTAX LnStreamEntry 280 ACCESS not-accessible 281 STATUS mandatory 282 DESCRIPTION "Each entry corresponds to one stream." 283 INDEX {lnStreamId} 284 ::= {lnStreamTable 1} 286 LnStreamEntry ::= SEQUENCE { 287 lnstreamId INTEGER, 288 lnInDataPkts Counter, 289 lnInRxPkts Counter, 290 lnInNullDataPkts Counter, 291 lnOuthackPkts Counter, 292 lnDroppedPkts Counter, 293 lnQos INTEGER, 294 lnState INTEGER, 295 lnSataChannel OCTET STRING 296 } 298 lnStreamId OBJECT-TYPE 299 SYNTAX INTEGER 300 ACCESS read-only 301 STATUS mandatory 302 DESCRIPTION "The unique identifier for the stream" 303 ::= {lnStreamEntry 1} 305 lnInDataPkts OBJECT-TYPE 306 SYNTAX Counter 307 ACCESS read-only 308 STATUS mandatory 309 DESCRIPTION "Number of data packets received" 310 ::= {lnStreamEntry 2} 312 lnInRxPkts OBJECT-TYPE 313 SYNTAX Counter 314 ACCESS read-only 315 STATUS mandatory 316 DESCRIPTION "Number of retransmission packets received" 317 ::= {lnStreamEntry 3} 319 lnInNullDataPkts OBJECT-TYPE 320 SYNTAX Counter 321 ACCESS read-only 322 STATUS mandatory 323 DESCRIPTION "Number of null data packets received" 324 ::= {lnStreamEntry 4} 326 lnOutHackPkts OBJECT-TYPE 327 SYNTAX Counter 328 ACCESS read-only 329 STATUS mandatory 330 DESCRIPTION "Number of HACK packets sent to the parent node" 331 ::= {lnStreamEntry 5} 333 lnDroppedPkts OBJECT-TYPE 334 SYNTAX Counter 335 ACCESS read-only 336 STATUS mandatory 337 DESCRIPTION "Number of packets missed or dropped" 338 ::= {lnStreamEntry 6} 340 lnQos OBJECT-TYPE 341 SYNTAX INTEGER { 342 unordered(1), 343 ordered(2) 344 } 345 ACCESS read-only 346 STATUS mandatory 347 DESCRIPTION "The current QoS for the stream" 348 ::= {lnStreamEntry 7} 350 lnState OBJECT-TYPE 351 SYNTAX INTEGER { 352 joining(1), 353 joinAck(2), 354 started(3), 355 completed(4) 356 } 357 ACCESS read-only 358 STATUS mandatory 359 DESCRIPTION "Current state of the stream" 360 ::= {lnStreamEntry 8} 362 lnDataChannel OBJECT-TYPE 363 SYNTAX OCTET STRING 364 ACCESS read-only 365 STATUS mandatory 366 DESCRIPTION "Data channel used for this stream" 367 ::= {lnStreamEntry 9} 369 -------------- 370 -- Group sd -- 371 -------------- 373 sdAdmitRate OBJECT-TYPE 374 SYNTAX INTEGER 375 ACCESS read-write 376 STATUS mandatory 377 DESCRIPTION "Admit rate specified by the sender application to 378 control 379 the bandwidth utilization" 380 ::= {sd 1} 382 sdDataQSize OBJECT-TYPE 383 SYNTAX INTEGER 384 ACCESS read-write 385 STATUS mandatory 386 DESCRIPTION "Current data queue size for the sender. It can be 387 changed 388 at run-time" 389 ::= {sd 2} 391 sdState OBJECT-TYPE 392 SYNTAX INTEGER 393 ACCESS read-only 394 STATUS mandatory 395 DESCRIPTION "State of the stream" 396 ::= {sd 3} 398 sdInHackPkts OBJECT-TYPE 399 SYNTAX Counter 400 ACCESS read-only 401 STATUS mandatory 402 DESCRIPTION "Number of HACK packets received" 403 ::= {sd 4} 405 sdInHackPkts OBJECT-TYPE 406 SYNTAX Counter 407 ACCESS read-only 408 STATUS mandatory 409 DESCRIPTION "" 410 ::= {sd 5} 412 sdOutDataPkts OBJECT-TYPE 413 SYNTAX Counter 414 ACCESS read-only 415 STATUS mandatory 416 DESCRIPTION "The number of data packets sent" 417 ::= {sd 6} 419 sdOutNullDataPkts OBJECT-TYPE 420 SYNTAX Counter 421 ACCESS read-only 422 STATUS mandatory 423 DESCRIPTION "The number of null data packets sent" 424 ::= {sd 7} 426 sdQos OBJECT-TYPE 427 SYNTAX INTEGER { 428 unordered(1), 429 ordered(2) 430 } 431 ACCESS read-only 432 STATUS mandatory 433 DESCRIPTION "The QoS quality of service set for this stream" 434 ::= {sd 8} 436 sdQFullCounter OBJECT-TYPE 437 SYNTAX INTEGER 438 ACCESS read-only 439 STATUS mandatory 440 DESCRIPTION "The number of times the data queue was full. If this 441 number is higher than data queue size should be 442 increased to get better performance." 443 ::= {sd 9} 445 sdTopNode OBJECT-TYPE 446 SYNTAX OCTET STRING 447 ACCESS read-only 448 STATUS mandatory 449 DESCRIPTION "An ascii string for top node's address and port 450 in the format xxx.xxx.xxx.xxx:nnnnn" 451 ::= {sd 10} 453 lowAdmitRate OBJECT-TYPE 454 SYNTAX INTEGER 455 ACCESS read-only 456 STATUS mandatory 457 DESCRIPTION "The lowest Admit rate provided by the sender 458 application. 459 In case of congestion, sender can lower the Admit Rate 460 to 461 lowAdmitRate." 462 ::= {sd 11} 464 highAdmitRate OBJECT-TYPE 465 SYNTAX INTEGER 466 ACCESS read-only 467 STATUS mandatory 468 DESCRIPTION "The highest Admit rate provided by the sender 469 application. " 470 ::= {sd 12} 472 -------------- 473 -- Group ag -- 474 -------------- 476 agParentAddress OBJECT-TYPE 477 SYNTAX IpAddress 478 ACCESS read-only 479 STATUS mandatory 480 DESCRIPTION "IP Address of the parent node in the RMTP tree" 481 ::= {ag 1} 483 agParentPort OBJECT-TYPE 484 SYNTAX INTEGER 485 ACCESS read-only 486 STATUS mandatory 487 DESCRIPTION "UDP port of the parent node in the RMTP tree" 488 ::= {ag 2} 490 agMaxChildren OBJECT-TYPE 491 SYNTAX Gauge 492 ACCESS read-only 493 STATUS mandatory 494 DESCRIPTION "The maximum number of children at any time" 495 ::= {ag 3} 497 agChildRejectCount OBJECT-TYPE 498 SYNTAX Counter 499 ACCESS read-only 500 STATUS mandatory 501 DESCRIPTION "The number of children rejected by the node" 502 ::= {ag 4} 504 agChildTable OBJECT-TYPE 505 SYNTAX SEQUENCE OF ChildEntry 506 ACCESS not-accessible 507 STATUS mandatory 508 DESCRIPTION "The Child table - basic information." 509 ::= {ag 5 } 511 agChildEntry OBJECT-TYPE 512 SYNTAX AgChildEntry 513 ACCESS not-accessible 514 STATUS mandatory 515 DESCRIPTION "Each entry corresponds to one Child." 516 INDEX { agMod } 517 ::= {agChildTable 1} 519 AgChildEntry ::= SEQUENCE { 520 agMod INTEGER, 521 agStreamCount INTEGER 522 } 524 agMod OBJECT-TYPE 525 SYNTAX INTEGER 526 ACCESS read-only 527 STATUS mandatory 528 DESCRIPTION "The mod number assigned by the parent node" 529 ::= {agChildEntry 1} 531 agStreamCount OBJECT-TYPE 532 SYNTAX INTEGER 533 ACCESS read-only 534 STATUS mandatory 535 DESCRIPTION "The number of streams received by the node" 536 ::= {agChildEntry 2} 538 agStreamTable OBJECT-TYPE 539 SYNTAX SEQUENCE OF AgStreamEntry 540 ACCESS not-accessible 541 STATUS mandatory 542 DESCRIPTION "The Stream table - basic information." 543 ::= {ag 6 } 545 agStreamEntry OBJECT-TYPE 546 SYNTAX AgStreamEntry 547 ACCESS not-accessible 548 STATUS mandatory 549 DESCRIPTION "Each entry corresponds to one stream." 550 INDEX {agStreamId} 551 ::= {agStreamTable 1} 553 AgStreamEntry ::= SEQUENCE { 554 agStreamId INTEGER, 555 agInHackPkts Counter, 556 agOuthackPkts Counter, 557 agChildCount INTEGER, 558 agState INTEGER, 559 agMaxLossRate INTEGER, 560 agMaxLossRateAddress IpAddress 561 } 563 agStreamId OBJECT-TYPE 564 SYNTAX INTEGER 565 ACCESS read-only 566 STATUS mandatory 567 DESCRIPTION "The unique identifier for the stream" 568 ::= {agStreamEntry 1} 570 agInHackPkts OBJECT-TYPE 571 SYNTAX Counter 572 ACCESS read-only 573 STATUS mandatory 574 DESCRIPTION "Number of HACK packets received" 575 ::= {agStreamEntry 2} 577 agOutHackPkts OBJECT-TYPE 578 SYNTAX Counter 579 ACCESS read-only 580 STATUS mandatory 581 DESCRIPTION "Number of HACK packets sent" 582 ::= {agStreamEntry 3} 584 agChildCount OBJECT-TYPE 585 SYNTAX INTEGER 586 ACCESS read-only 587 STATUS mandatory 588 DESCRIPTION "Number of children receiving this stream" 589 ::= {agStreamEntry 4} 591 agState OBJECT-TYPE 592 SYNTAX INTEGER { 593 joining(1), 594 joinAck(2), 595 started(3), 596 completed(4) 597 } 598 ACCESS read-only 599 STATUS mandatory 600 DESCRIPTION "Current state of the stream" 601 ::= {agStreamEntry 5} 603 agMaxLossRate OBJECT-TYPE 604 SYNTAX INTEGER 605 ACCESS read-only 606 STATUS mandatory 607 DESCRIPTION "Maximum loss rate of all the child nodes" 608 ::= {agStreamEntry 6} 610 agMaxLossRateAddress OBJECT-TYPE 611 SYNTAX IpAddress 612 ACCESS read-only 613 STATUS mandatory 614 DESCRIPTION "IP Address of the node having maximum loss" 615 ::= {agStreamEntry 7} 617 -------------- 618 -- Group tn -- 619 -------------- 621 tnMaxChildren OBJECT-TYPE 622 SYNTAX Gauge 623 ACCESS read-only 624 STATUS mandatory 625 DESCRIPTION "The maximum number of children at any time" 626 ::= {tn 1} 628 tnChildRejectCount OBJECT-TYPE 629 SYNTAX Counter 630 ACCESS read-only 631 STATUS mandatory 632 DESCRIPTION "The number of children rejected by the node" 633 ::= {tn 2} 635 -------------------------------------------------- 636 -- Global Parameters maintained at the top node -- 637 -------------------------------------------------- 638 branchFactor OBJECT-TYPE 639 SYNTAX INTEGER 640 ACCESS read-write 641 STATUS mandatory 642 DESCRIPTION "The maximum number of children for any node in the 643 tree" 644 ::= {tn 3} 646 thackConstant OBJECT-TYPE 647 SYNTAX INTEGER 648 ACCESS read-write 649 STATUS mandatory 650 DESCRIPTION "The scaling coefficient for thack" 651 ::= {tn 4} 653 overHead OBJECT-TYPE 654 SYNTAX INTEGER 655 ACCESS read-write 656 STATUS mandatory 657 DESCRIPTION "The maximum number of HACKs should be received, 658 for each data packet, at control nodes" 659 ::= {tn 5} 661 tJoinResponse OBJECT-TYPE 662 SYNTAX INTEGER 663 ACCESS read-write 664 STATUS mandatory 665 DESCRIPTION "Maximum time to wait for a response to a JoinStream 666 request" 667 ::= {tn 6} 669 rJoin OBJECT-TYPE 670 SYNTAX INTEGER 671 ACCESS read-write 672 STATUS mandatory 673 DESCRIPTION "The number of retries of the JoinRequest befor 674 declaring 675 the parent unreachable" 676 ::= {tn 7} 678 tHB OBJECT-TYPE 679 SYNTAX INTEGER 680 ACCESS read-write 681 STATUS mandatory 682 DESCRIPTION "The time interval at which control nodes multicast 683 heartbeat 684 packets" 685 ::= {tn 8} 687 failureConstant OBJECT-TYPE 688 SYNTAX INTEGER 689 ACCESS read-write 690 STATUS mandatory 691 DESCRIPTION "The threshold time for failure detection" 692 ::= {tn 9} 694 tNulldataMax OBJECT-TYPE 695 SYNTAX INTEGER 696 ACCESS read-write 697 STATUS mandatory 698 DESCRIPTION "Maximum time interval between NullData packets" 699 ::= {tn 10} 701 thackMax OBJECT-TYPE 702 SYNTAX INTEGER 703 ACCESS read-write 704 STATUS mandatory 705 DESCRIPTION "Maximum time allowed between HACK transmission for 706 each node" 707 ::= {tn 11} 709 rxMax OBJECT-TYPE 710 SYNTAX INTEGER 711 ACCESS read-write 712 STATUS mandatory 713 DESCRIPTION "Maximum number of retransmissions for a data packet" 714 ::= {tn 12} 716 optimistic OBJECT-TYPE 717 SYNTAX INTEGER { 718 pessimistic(0) 719 optimistic(1), 720 } 721 ACCESS read-write 722 STATUS mandatory 723 DESCRIPTION "Defines the stability property for the RMTP-II tree" 724 ::= {tn 13} 726 tnChildTable OBJECT-TYPE 727 SYNTAX SEQUENCE OF TnChildEntry 728 ACCESS not-accessible 729 STATUS mandatory 730 DESCRIPTION "The Child table - basic information." 731 ::= {tn 14 } 733 tnChildEntry OBJECT-TYPE 734 SYNTAX TnChildEntry 735 ACCESS not-accessible 736 STATUS mandatory 737 DESCRIPTION "Each entry corresponds to one Child." 738 INDEX { tnMod } 739 ::= {tnChildTable 1} 741 TnChildEntry ::= SEQUENCE { 742 tnMod INTEGER, 743 tnStreamCount INTEGER 744 } 746 tnMod OBJECT-TYPE 747 SYNTAX INTEGER 748 ACCESS read-only 749 STATUS mandatory 750 DESCRIPTION "The mod number assigned by the parent node" 751 ::= {tnChildEntry 1} 753 tnStreamCount OBJECT-TYPE 754 SYNTAX INTEGER 755 ACCESS read-only 756 STATUS mandatory 757 DESCRIPTION "The number of streams received by the node" 758 ::= {tnChildEntry 2} 760 tnStreamTable OBJECT-TYPE 761 SYNTAX SEQUENCE OF TnStreamEntry 762 ACCESS not-accessible 763 STATUS mandatory 764 DESCRIPTION "The Stream table - basic information." 765 ::= {tn 4 } 767 tnStreamEntry OBJECT-TYPE 768 SYNTAX TnStreamEntry 769 ACCESS not-accessible 770 STATUS mandatory 771 DESCRIPTION "Each entry corresponds to one stream." 772 INDEX {tnStreamId} 773 ::= {tnStreamTable 1} 775 TnStreamEntry ::= SEQUENCE { 776 tnStreamId INTEGER, 777 tnInHackPkts Counter, 778 tnOuthackPkts Counter, 779 tnChildCount INTEGER, 780 tnState INTEGER, 781 tnMaxLossRate INTEGER, 782 tnMaxLossRateAddress IpAddress 783 } 785 tnStreamId OBJECT-TYPE 786 SYNTAX INTEGER 787 ACCESS read-only 788 STATUS mandatory 789 DESCRIPTION "The unique identifier for the stream" 790 ::= {tnStreamEntry 1} 792 tnInHackPkts OBJECT-TYPE 793 SYNTAX Counter 794 ACCESS read-only 795 STATUS mandatory 796 DESCRIPTION "Number of HACK packets received" 797 ::= {tnStreamEntry 2} 799 tnOutHackPkts OBJECT-TYPE 800 SYNTAX Counter 801 ACCESS read-only 802 STATUS mandatory 803 DESCRIPTION "Number of HACK packets sent" 804 ::= {tnStreamEntry 3} 806 tnChildCount OBJECT-TYPE 807 SYNTAX INTEGER 808 ACCESS read-only 809 STATUS mandatory 810 DESCRIPTION "Number of children receiving this stream" 811 ::= {tnStreamEntry 4} 813 tnState OBJECT-TYPE 814 SYNTAX INTEGER { 815 joining(1), 816 joinAck(2), 817 started(3), 818 completed(4) 819 } 820 ACCESS read-only 821 STATUS mandatory 822 DESCRIPTION "Current state of the stream" 823 ::= {tnStreamEntry 5} 825 tnMaxLossRate OBJECT-TYPE 826 SYNTAX INTEGER 827 ACCESS read-only 828 STATUS mandatory 829 DESCRIPTION "Maximum loss rate of all the child nodes" 830 ::= {tnStreamEntry 6} 832 tnMaxLossRateAddress OBJECT-TYPE 833 SYNTAX IpAddress 834 ACCESS read-only 835 STATUS mandatory 836 DESCRIPTION "IP Address of the node having maximum loss" 837 ::= {tnStreamEntry 7} 839 tnSenderTable OBJECT-TYPE 840 SYNTAX SEQUENCE OF SenderEntry 841 ACCESS not-accessible 842 STATUS mandatory 843 DESCRIPTION "The sender table - basic information." 844 ::= {tn 5 } 846 tnSenderEntry OBJECT-TYPE 847 SYNTAX SenderEntry 848 ACCESS not-accessible 849 STATUS mandatory 850 DESCRIPTION "Each entry corresponds to one sender." 851 INDEX {tnStreamId} 852 ::= {tnSenderTable 1} 854 SenderEntry ::= SEQUENCE { 855 tnSdstreamId INTEGER, 856 tnSdAddress IpAddress, 857 tnSdPort INTEGER 858 } 860 tnSdStreamId OBJECT-TYPE 861 SYNTAX INTEGER 862 ACCESS read-only 863 STATUS mandatory 864 DESCRIPTION "The unique identifier for the stream" 865 ::= {tnSenderEntry 1} 867 tnSdAddress OBJECT-TYPE 868 SYNTAX IpAddress 869 ACCESS read-only 870 STATUS mandatory 871 DESCRIPTION "IP Address of the sender node" 872 ::= {tnSenderEntry 2} 874 tnSdPort OBJECT-TYPE 875 SYNTAX INTEGER 876 ACCESS read-only 877 STATUS mandatory 878 DESCRIPTION "UDP Port of the sender node" 879 ::= {tnSenderEntry 3} 881 ---------------------------------------------------- 882 -- The configuration table for each of the sender -- 883 -- each entry gives the current, minimum and -- 884 -- maximum admit rate for the sender. -- 885 ---------------------------------------------------- 887 tnSdConfigTable OBJECT-TYPE 888 SYNTAX SEQUENCE OF SenderConfigEntry 889 ACCESS not-accessible 890 STATUS mandatory 891 DESCRIPTION "The sender Config table - Rate information." 892 ::= {tn 6 } 894 tnSenderConfigEntry OBJECT-TYPE 895 SYNTAX SenderConfigEntry 896 ACCESS not-accessible 897 STATUS mandatory 898 DESCRIPTION "Each entry corresponds to one sender, sender index is 899 used as the INDEX for this table" 900 INDEX {tnSdIndex} 901 ::= {tnSenderConfigTable 1} 903 SenderConfigEntry::= SEQUENCE { 904 tnSdIndex INTEGER, 905 sdCurrentRate INTEGER, 906 sdMaxRate INTEGER, 907 sdMinRate INTEGER, 908 sdCommand INTEGER 909 } 911 tnSdIndex OBJECT-TYPE 912 SYNTAX INTEGER 913 ACCESS read-only 914 STATUS mandatory 915 DESCRIPTION "The unique identifier for the sender" 916 ::= {tnSenderConfigEntry 1} 918 sdCurrentRate OBJECT-TYPE 919 SYNTAX INTEGER 920 ACCESS read-write 921 STATUS mandatory 922 DESCRIPTION "The current admit rate for the sender node" 923 ::= {tnSenderConfigEntry 2} 925 sdMaxRate OBJECT-TYPE 926 SYNTAX INTEGER 927 ACCESS read-write 928 STATUS mandatory 929 DESCRIPTION "The maximum admit rate for the sender node" 930 ::= {tnSenderConfigEntry 3} 932 sdMinRate OBJECT-TYPE 933 SYNTAX INTEGER 934 ACCESS read-write 935 STATUS mandatory 936 DESCRIPTION "The minimum admit rate for the sender node" 937 ::= {tnSenderConfigEntry 4} 939 sdCommand OBJECT-TYPE 940 SYNTAX INTEGER 941 ACCESS write-only 942 STATUS mandatory 943 DESCRIPTION "The commands that can be passed to the sender node" 944 ::= {tnSenderConfigEntry 5} 946 -------------- 947 -- Group dr -- 948 -------------- 950 drParentAddress OBJECT-TYPE 951 SYNTAX IpAddress 952 ACCESS read-only 953 STATUS mandatory 954 DESCRIPTION "IP Address of the parent node in the RMTP tree" 955 ::= {dr 1} 957 drParentPort OBJECT-TYPE 958 SYNTAX INTEGER 959 ACCESS read-only 960 STATUS mandatory 961 DESCRIPTION "UDP port of the parent node in the RMTP tree" 962 ::= {dr 2} 964 drMaxChildren OBJECT-TYPE 965 SYNTAX Gauge 966 ACCESS read-only 967 STATUS mandatory 968 DESCRIPTION "The maximum number of children at any time" 969 ::= {dr 3} 971 drChildRejectCount OBJECT-TYPE 972 SYNTAX Counter 973 ACCESS read-only 974 STATUS mandatory 975 DESCRIPTION "The number of children rejected by the node" 976 ::= {dr 4} 978 drChildTable OBJECT-TYPE 979 SYNTAX SEQUENCE OF ChildEntry 980 ACCESS not-accessible 981 STATUS mandatory 982 DESCRIPTION "The Child table - basic information." 983 ::= {dr 5 } 985 drChildEntry OBJECT-TYPE 986 SYNTAX DrChildEntry 987 ACCESS not-accessible 988 STATUS mandatory 989 DESCRIPTION "Each entry corresponds to one Child." 990 INDEX { drMod } 991 ::= {drChildTable 1} 993 DrChildEntry ::= SEQUENCE { 994 drMod INTEGER, 995 drStreamCount INTEGER 996 } 998 drMod OBJECT-TYPE 999 SYNTAX INTEGER 1000 ACCESS read-only 1001 STATUS mandatory 1002 DESCRIPTION "The mod number assigned by the parent node" 1003 ::= {drChildEntry 1} 1005 drStreamCount OBJECT-TYPE 1006 SYNTAX INTEGER 1007 ACCESS read-only 1008 STATUS mandatory 1009 DESCRIPTION "The number of streams received by the node" 1010 ::= {drChildEntry 2} 1012 drStreamTable OBJECT-TYPE 1013 SYNTAX SEQUENCE OF DrStreamEntry 1014 ACCESS not-accessible 1015 STATUS mandatory 1016 DESCRIPTION "The Stream table - basic information." 1017 ::= {dr 6 } 1019 drStreamEntry OBJECT-TYPE 1020 SYNTAX DrStreamEntry 1021 ACCESS not-accessible 1022 STATUS mandatory 1023 DESCRIPTION "Each entry corresponds to one stream." 1024 INDEX {drStreamId} 1025 ::= {drStreamTable 1} 1027 DrStreamEntry ::= SEQUENCE { 1028 drStreamId INTEGER, 1029 drInHackPkts Counter, 1030 drOuthackPkts Counter, 1031 drChildCount INTEGER, 1032 drState INTEGER, 1033 drMaxLossRate INTEGER, 1034 drMaxLossRateAddress IpAddress 1035 } 1037 drStreamId OBJECT-TYPE 1038 SYNTAX INTEGER 1039 ACCESS read-only 1040 STATUS mandatory 1041 DESCRIPTION "The unique identifier for the stream" 1042 ::= {drStreamEntry 1} 1044 drInHackPkts OBJECT-TYPE 1045 SYNTAX Counter 1046 ACCESS read-only 1047 STATUS mandatory 1048 DESCRIPTION "Number of HACK packets received" 1049 ::= {drStreamEntry 2} 1051 drOutHackPkts OBJECT-TYPE 1052 SYNTAX Counter 1053 ACCESS read-only 1054 STATUS mandatory 1055 DESCRIPTION "Number of HACK packets sent" 1056 ::= {drStreamEntry 3} 1058 drChildCount OBJECT-TYPE 1059 SYNTAX INTEGER 1060 ACCESS read-only 1061 STATUS mandatory 1062 DESCRIPTION "Number of children receiving this stream" 1063 ::= {drStreamEntry 4} 1065 drState OBJECT-TYPE 1066 SYNTAX INTEGER { 1067 joining(1), 1068 joinAck(2), 1069 started(3), 1070 completed(4) 1071 } 1072 ACCESS read-only 1073 STATUS mandatory 1074 DESCRIPTION "Current state of the stream" 1075 ::= {drStreamEntry 5} 1077 drMaxLossRate OBJECT-TYPE 1078 SYNTAX INTEGER 1079 ACCESS read-only 1080 STATUS mandatory 1081 DESCRIPTION "Maximum loss rate of all the child nodes" 1082 ::= {drStreamEntry 6} 1084 drMaxLossRateAddress OBJECT-TYPE 1085 SYNTAX IpAddress 1086 ACCESS read-only 1087 STATUS mandatory 1088 DESCRIPTION "IP Address of the node having maximum loss" 1089 ::= {drStreamEntry 7} 1091 END 1093 APPENDIX D - FORWARD ERROR CORRECTION 1095 Recent work [NB96, NBT97, Rizzo97] has shown the benefits of 1096 incorporating forward error correction (FEC) into reliable multicast 1097 protocols. RMTP-II supports two modes of FEC: Proactive and 1098 Reactive. 1100 Proactive FEC is a mechanism by which parity packets are sent along 1101 with the data packets. The receivers use the parity packets to 1102 recover the missing data packets. This is used in environments where 1103 there is no back channel to get feedback from the receivers to the 1104 sender, and to support real time applications. 1106 Reactive FEC is a mechanism by which the sender encodes and sends 1107 parity packets only if it gets notification about missed data 1108 packets. The sender sends parity packets instead of retransmitting 1109 the data packets. The receivers are able to repair different lost 1110 packets with these parity packets. This is used in environments 1111 where receivers face independent loss. For example, if receivers are 1112 connected to the network by modem, the losses at the various 1113 receivers may be independent. If each receiver looses a different 1114 packet then there may be much transmission. Each receiver may be 1115 able to recover its missed data when a parity packet is transmitted. 1117 Algorithm 1119 Parity packets are sent using the reserved sequence number zero and 1120 the FEC option. The FEC option has three fields: 1122 BeginSeq: 1123 This is the beginning data packet sequence number for the FEC 1124 block. 1126 EndSeq: 1127 This is the end data packet sequence number for the FEC block. 1129 Index: 1130 This is the index number used for the parity packet. 1132 All data packets within a block need to be of fixed size to calculate 1133 parity. When transmitting, the sender must find the max size, Smax, 1134 from all the packets in the FEC block. All bytes in the block 1135 between the actual packet length and Smax are set to zero. This is 1136 only done for FEC calculation. 1138 Proactive FEC 1140 The following parameters are required: 1142 Bmax: 1143 This is the maximum block size (number of packets in a block). 1145 P: 1146 This is the number of parity packets per block. 1148 Tmax: 1149 This is the maximum time interval, after which a parity packet is 1150 forced out. 1152 When the sender sends the first packet of a block, it schedules a 1153 timer for time Tmax. After it sends Bmax packets, the sender computes 1154 P parity packets for Bmax packets and then sends the parity packets 1155 with sequence number zero. If the timer expires, then compute P 1156 parity packets just for the number of packets that have been sent. 1158 If the receiver receives a parity packet, it determines whether it 1159 has missed any data packets within the FEC block. The FEC option in 1160 the parity packet has the block information. If no data packets are 1161 missing within the FEC block it ignores the parity packets. 1163 If a receiver determines that one or more data packets are missed 1164 within a FEC block, it waits to receive that many parity packets. 1165 When it receives the required parity packets, the receiver passes the 1166 received data packets and parity packets to the FEC decoder to 1167 recover the missed data packets. 1169 If the parity packets received are less than the missed data packets 1170 within a FEC block, the FEC decoder cannot generate the missed data 1171 packets. In such a situation, it waits to recover the missed data 1172 packets from the data retransmissions done by the sender. 1174 Reactive FEC 1176 The following parameters are required: 1178 Bmax: 1179 This is the maximum block size (the number of packets in a block. 1180 P: 1181 The number of parity packets per block. 1183 When the sender receives a HACK, it creates FEC blocks from Lowest 1184 Sequence Number to Highest Sequence Number. It computes parity 1185 packets for each block and sends the parity packets instead of 1186 retransmitting the data packets. 1188 The receivers use these parity packets to compute the missed data 1189 packets. If the receiver cannot compute the missed data packets from 1190 the parity packets, it uses the FEC option in the HACK packet to 1191 notify the sender to retransmit the data packet instead of sending 1192 parity packets. The control node propagates this FEC option to the 1193 sender. 1195 If the sender receives a HACK with the FEC option to retransmit the 1196 data packets set, it will retransmit the data packets and not send 1197 parity packets. 1199 FEC option for HACK packet 1201 This option allows the receivers to request retransmission of data 1202 instead of parity packets. 1204 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | A | OTYPE | LENGTH | SendData | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 A: set to 00 skip option, process packet 1212 OTYPE: set to 11 Gcast FEC 1214 LENGTH: set to 1 1216 SendData: If set, then all the control nodes, propagate this option 1217 to the sender. The sender retransmits the data packets instead of 1218 sending parity packets. 1220 FEC option for data packet This option allows the sender to send FEC 1221 parity packets to receivers. 1223 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | A | OTYPE | LENGTH | Reserved | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | BeginSeq | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | EndSeq | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | ParityIndex | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 A: set to 00 - skip option, process packet 1236 OTYPE: set to 11 - Gcast FEC 1238 LENGTH: set to 4 1240 BeginSeq: This is the beginning data packet sequence number for the 1241 FEC block. 1243 EndSeq: This is the end data packet sequence number for the FEC 1244 block. 1246 ParityIndex: This is the index number used for the parity packet. 1248 References [NB96] J. Nonnenmacher and E.W. Biersack, "Reliable 1249 Multicast: Where to use Forward Error Correction", Proc. 5th. 1250 Workshop on Protocols for High Speed Networks, Sophia Antipolis, 1251 France, Oct. 1996. 1253 [NBT97] J. Nonnenmacher, E. W. Biersack, and Don Towsley. "Parity- 1254 Based Loss Recovery for Reliable Multicast Transmission", In Proc. of 1255 ACM SIGCOMM '97, Cannes, France, September 1997. 1257 [Rizzo97] L. Rizzo, "Effective erasure codes for reliable computer 1258 communications protocols", DEIT Technical Report LR-970115. 1260 APPENDIX E - TIME BOUNDED RELIABILITY 1262 RMTP includes a new quality of service level called Time Bounded 1263 Reliability. This QoS is designed to support synchronous streaming 1264 data types, such as streaming audio and video, and real time 1265 financial data. Packets with this QoS level are assigned a maximum 1266 latency Bound, and the receiver attempts to deliver the packets with 1267 a QoS of Source Ordered for up to Bound seconds. After that time 1268 elapses, the receiver stops requesting retransmission of the missing 1269 packets and "delivers" them to the application as an error code. 1270 This allows packets which have been blocking on the missing packets 1271 (because they have higher sequence numbers than the missing ones) to 1272 be delivered within a fixed amount of time after they are sent. Each 1273 stream can have only a single QoS and Bound associated with it, and 1274 this is fixed for the duration of the stream. 1276 We define the following variables for a given packet. 1278 Tsent: The time at the sender when the packet was generated (based 1279 on sender's clock). 1281 Treceived: The time at the receiver when the packet was received 1282 (based on receiver's clock). 1284 Lmin: The minimum physical latency for a packet to be delivered from 1285 the sender to the receiver. 1287 Bound: The maximum time allowed for recovery of a packet. 1289 Cdiff: The difference in clocks between the sender and the reciever. 1291 Tdrop: The time at the receiver when the packet should be declared 1292 dropped (based on receiver's clock). 1294 In order to be scalable, the protocol can not rely on any true clock 1295 synchronization algorithms for determining Cdiff. Instead, Lmin is 1296 defined as the minimum observed latency between the two computers, 1297 which occurs when (Treceived-Tsent) is the smallest. When each 1298 packet is received, the receiver calculates this Diff=Treceived- 1299 Tsent, and compares it to Cdiff. If it is smaller than Cdiff (which 1300 is initially set to positive infinity), then Cdiff is set to Diff. 1301 Tdrop for a given packet is then defined as Bound - Tsent + Cdiff. 1302 Given this, the algorithm may not give accurate results when: Bound 1303 is smaller than the sum of Lmin plus the timer resolution on the 1304 receivers' machines. During the initial packets sent in a data 1305 stream, when Cdiff has not yet been measured accurately. 1307 When a packet is sent, Tsent is included in the packet's header. 1309 Tsent is the time at which the sender's transport received the 1310 packet, not adjusted for daylight savings time. All clock 1311 measurements are not adjusted for daylight savings time, to avoid any 1312 discontinuities in operation when a computer adjusts its internal 1313 clock for this time change. When the packet is received, the current 1314 clock at the receiver is measured as Treceived, and Cdiff is updated 1315 if necessary. 1317 The packets in each receiver's incoming data queue are sorted by 1318 sequence number, using sequence number arithmetic. For the packet in 1319 the queue with the lowest sequence number, the current time at the 1320 receiver is regularly compared against Tdrop, as calculated with 1321 Tsent for that packet and the current values of Cdiff and Bound. If 1322 the current time is larger than Tdrop, then all of the missing 1323 packets with smaller sequence numbers are "delivered" to the 1324 application as error codes, and the tested packet is delivered as 1325 well. When this occurs, the receivers will stop requesting 1326 retransmission for the "delivered" missing packets, and will consider 1327 them to have gone stable. 1329 APPENDIX F - WORK IN PROGRESS 1331 Work is currently in progress for the following areas: 1333 1) Security considerations 1335 2) Analysis of protocol performance 1337 3) Proof of protocol correctness 1339 4) Integration with generic router assist mechanisms 1341 5) Definition of automatic tree configuration algorithms for use in 1342 the session manager 1344 6) Analysis of congestion control algorithms relative to TCP traffic 1346 7) Header compression, including HACK bitfield compression 1348 The authors welcome any and all feedback on this draft, as well as 1349 offers to collaborate on any of these work in progress areas.