1 / 14

TRACK Protocol Instantiation Update Brian Whetten brian@whetten Dah Ming Chiu

TRACK Protocol Instantiation Update Brian Whetten brian@whetten.net Dah Ming Chiu dahming.chiu@sun.com Miriam Kadansky miriam.kadansky@sun.com Gursel Taskale gursel@tibco.com. Status. Three drafts available www.whetten.net/reliable_multicast.htm draft-ietf-rmt-track-bb-02.txt

josephine-kirkland
Download Presentation

TRACK Protocol Instantiation Update Brian Whetten brian@whetten Dah Ming Chiu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TRACK Protocol Instantiation Update Brian Whetten brian@whetten.net Dah Ming Chiu dahming.chiu@sun.com Miriam Kadansky miriam.kadansky@sun.com Gursel Taskale gursel@tibco.com

  2. Status • Three drafts available • www.whetten.net/reliable_multicast.htm • draft-ietf-rmt-track-bb-02.txt • draft-ietf-rmt-track-pi-udp-00.txt • draft-ietf-rmt-tree-bb-03.txt • First complete set of documents • Integration interfaces are not yet 100% specified • Instantiated over UDP as a reference • Completion requires integration with external components and refinement • New PI over NORM or PGM • TFMCC integration to make UDP PI deployable

  3. Drivers • What are the applications for TRACK? • Multicast file transfer and content distribution • PGM is the de-facto standard today • Requires application level confirmation of delivery • Custom mission-critical business applications • Publish/subscribe and overlay networking • Requires application level confirmation of delivery • Requires reliability in the face of persistent failures • In order to be useful and viable, TRACK must • Provide application level confirmation of delivery • Support both existing and new multicast protocols • Support both RM transport and overlay networking

  4. Challenges • TRACK group has fallen behind • I take personal responsibility for this • Technical challenges • Integration of many BB’s led to overwhelming complexity • Three severely pared-down drafts are 100 pages • Integration of a PI on another PI • Direct integration with NORM BB’s = unmanageable complexity • Supporting both RMT charter and current commercial environment • Need to support existing protocols as well as new standards • Business challenges • Two primary authors are on sabbatical this year • The market for communications protocols is less than optimal – support for strategic initiatives is minimal

  5. Original TRACK Architecture TRACK PI TFMCC* TRACK BB Auto Tree NACK BB FEC BB Security NORM PI Network Level GRA BB Common Headers? * Optional

  6. New TRACK Architecture Multiple TRACK PI’s TFMCC TRACK BB Data Channel Protocol UDP, NORM, PGM, ALC Overlay Network SessionAdvertisement Auto Tree Ensures Goodput Optional Functions Application Reliability

  7. Original Integration with NORM/GRA Sender NACK Sender NACK-R NACK-R RH RH NACK Sender NACK Sender GRA GRA NACK-R NACK-R NACK-R NACK-R Receiver Receiver Receiver Receiver

  8. New Integration with Other Protocols Sender Data Channel Protocol (NACK, GRA, FEC, CC BB’s) Control Tree Data Channel RH Receiver TRACK Goodput Protocol

  9. Reference Instantiation A TRACK PI Over UDP TRACK BB Data Channel Protocol Add TFMCC? UDP SessionAdvertisement Auto Tree Ensures Goodput Optional Functions Application Reliability

  10. TRACK BB Functionality • Hierarchical Session Creation and Maintenance • Tree building • Failure detection and recovery • Distributed membership • Data Sessions • Transmission and retransmission • Reliability in the face of persistent failures • Flow control and buffer management • End of stream • TRACK Generation and Aggregation • Timing and aggregation

  11. TRACK BB Functionality • Statistics Reporting and Aggregation • Self describing data and aggregation types • Application Level Confirmed Delivery • Scaleable, flexible, reliable • Congestion Control Information Gathering • Efficient RTT measurements • Periodic status reports • Supports hierarchical schemes like restricted worst edge

  12. TRACK PI Functionality • Integration with Data Channel Protocol • One per PI • Primary responsibility for congestion control • Optional: Session Advertisement Integration • UDP PI includes simple multicast advertisements • This requires many-many multicast • Optional: Replacement Congestion Control • Could add in TFMCC, and take advantage of TRACK congestion control information

  13. Next Steps • Time to take stock of where we are at • Authors’ primary goals • Fulfill commitments in a timely fashion • Get closure within 6-12 months • Maintain IETF and personal standards • Robustness, safety, quality, usefulness, viability • Capture and preserve the knowledge and lessons from the RMT process • Next step: Community feedback on three drafts • Particularly with regards to architecture, usefulness, and robustness

  14. Potential Outcomes • Option 1: Remove TRACK from charter • Advantage: Rapid closure • Disadvantage: Leaves a hole in needed functionality • Option 2: Push for experimental RFC status • Advantage: Completes original charter • Disadvantage: Unrealistic given current resources • Option 3: Informational RFC? • Is this a realistic compromise? • Feedback?

More Related