RFC 3048
Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer 🎀
Okay bestie, this is RFC 3048 💖 It's Informational, which means it's sharing info with the Internet community and it does not specify an Internet standard of any kind 🌸 It was published in January 2001 and written by B. Whetten (Talarian), L. Vicisano (Cisco), R. Kermode (Motorola), M. Handley (ACIRI 9), S. Floyd (ACIRI), and M. Luby (Digital Fountain) 👑 The header doesn't list any RFCs it obsoletes or updates, so it's a standalone main character 🦋
Status of This Memo ✨
This memo gives information to the Internet community. It is not a standard of any kind 💅 Distribution of this memo is unlimited 🌈
Copyright Notice 🫶
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🔥
Okay so this doc is a framework for standardizing bulk-data reliable multicast transport 🧚 It's built on what we learned from deploying a bunch of contemporary reliable multicast transports, and it tries to pull out the stuff they all have in common into a set of building blocks ✨ The idea is that certain components shared by several protocol classes get standardized as "building blocks" 🧩 Whatever's left (the super protocol-specific, tightly intertwined functions) gets called "protocol cores" 💜 So each protocol is basically a "protocol core" merged with some "building blocks" that can be reused across lots of protocols. Iconic, right? 😭
Table of Contents 🍓
1 Introduction .................................................. 2
1.1 Protocol Families ........................................... 5
2 Building Blocks Rationale ..................................... 6
2.1 Building Blocks Advantages .................................. 6
2.2 Building Block Risks ........................................ 7
2.3 Building Block Requirements ................................. 8
3 Protocol Components ........................................... 8
3.1 Sub-Components Definition ................................... 9
4 Building Block Recommendations ................................ 12
4.1 NACK-based Reliability ...................................... 13
4.2 FEC coding .................................................. 13
4.3 Congestion Control .......................................... 13
4.4 Generic Router Support ...................................... 14
4.5 Tree Configuration .......................................... 14
4.6 Data Security ............................................... 15
4.7 Common Headers .............................................. 15
4.8 Protocol Cores .............................................. 15
5 Security ...................................................... 15
6 IANA Considerations ........................................... 15
7 Conclusions ................................................... 16
8 Acknowledgements .............................................. 16
9 References .................................................... 16
10 Authors' Addresses ........................................... 19
11 Full Copyright Statement ..................................... 201. Introduction ✨
Okay, so RFC 2357 lays out the requirements for reliable multicast protocols that the IETF will consider for standardization 📋 The list goes like this:
- Congestion Control. The protocol has to be safe to deploy across the widespread Internet 🔥 It must meet three mandates: a) it must achieve good throughput (so it must not consistently overload links with excess data or repair traffic), b) it must achieve good link utilization, and c) it must not starve competing flows 💅
- Scalability. The protocol should work under a bunch of conditions, including multiple network topologies, link speeds, and receiver set sizes 🌸 Honestly it matters more to understand how and when a protocol breaks than when it works 🙈
- Security. The protocol must be analyzed to show what's needed for it to cope with security and privacy issues 🔐 That covers its role in data confidentiality and sender authentication, plus how it defends against denial of service attacks 😭
These requirements are mostly about making sure standards are safe for widespread Internet deployment 🌈 A big reason the IETF could charter the RMT working group is the growing maturity of reliable multicast congestion control (RMCC) [HFW99] in the IRTF Reliable Multicast Research Group (RMRG) 🦋 RMCC only covers part of the reliable multicast design space, but the fun part is that the requirements it covers are also the most pressing application and market requirements 💖
A protocol's ability to meet the requirements of congestion control, scalability, and security is affected by a bunch of secondary requirements, described in a separate document [RFC2887] 🧚 Here's the summary:
- Ordering Guarantees. A protocol must offer at least one of source ordered or unordered delivery guarantees 📦 Total ordering across multiple senders is not recommended, since it makes scaling harder and can be done more easily at a higher level 🙅♀️
- Receiver Scalability. A protocol should be able to support a "large" number of simultaneous receivers per transport group 👑 A typical receiver set could be on the order of at least 1,000 - 10,000 simultaneous receivers per group, or could eventually scale up to millions of receivers in the large Internet 🌍
- Real-Time Feedback. Some versions of RMCC may require soft real-time feedback, so a protocol may provide some means for that information to be measured and sent back to the sender ⏱️ This doesn't mean the protocol has to deliver data in soft real-time, but it's an important application requirement that's easy to provide once you have real-time feedback 🫶
- Delivery Guarantees. Lots of applications need a logically defined unit (or units) of data delivered to multiple clients 🎁 Think a file or set of files, a software package, a stock quote or package of quotes, an event notification, a set of slides, or a frame or block from a video 🎬 An application data unit is a logically separable unit of data that's useful to the application 💜 Sometimes it fits in a single packet (like an event notification or stock quote), and other times it's way longer than a packet (like a software package) 📦 A protocol must provide good throughput of application data units to receivers, which means most of the data delivered to receivers is useful for recovering the application data unit they're trying to receive ✨ A protocol may optionally provide delivery confirmation, meaning a mechanism for receivers to tell the sender when data has been delivered 💌 There are two types: application data unit confirmation and packet confirmation 🦋 Application data unit confirmation is useful at the application level, like telling the application how far receivers have progressed and deciding when to stop sending packets about a particular application data unit 🌸 Packet confirmation is useful at the transport level, like telling the transport layer when it can release buffer space holding packets that have been confirmed as delivered 🧺 Packet level confirmation may also help with application data unit confirmation 💅
- Network Topologies. A protocol must not break the network when deployed across the full Internet 🌐 We know intranets will see the first wave of deployments though, so they're also super important to support 🏢 So support for satellite networks (including ones with terrestrial return paths or no return paths at all) is encouraged, but not required 🛰️
- Group Membership. Group membership algorithms must be scalable 🫂 Membership can be anonymous (the sender doesn't know the list of receivers), or fully distributed (the sender gets a count of receivers and, optionally, a list of failures) 🙈
- Example Applications. Some applications a RM protocol could be designed to support include multimedia broadcasts, real-time financial market data distribution, multicast file transfer, and server replication 🎀
In the rest of this document, these terms have a specific meaning: "protocol family", "protocol component", "building block", "protocol core", and "protocol instantiation" 📚 A "protocol family" is a broad class of RM protocols that share a common characteristic, and in this classification that characteristic is the mechanism used to achieve reliability 💖 A "protocol component" is a logical part of the protocol that addresses a particular functionality 🧩 A "building block" is a constituent of a protocol that implements one, more than one, or a part of a component 🧱 A "protocol core" is the set of functionality required to instantiate a complete protocol that isn't specified by any building block 💜 And finally, a "protocol instantiation" is an actual RM protocol defined in terms of building blocks and a protocol core 🌈✨
1.1. Protocol Families ✨
okay so the design-space document [RFC2887] also has a taxonomy of the most popular approaches people have proposed over the last ten years 🦋 after congestion control, the big challenge has been getting good throughput in a way that still scales to a huge number of receivers. for protocols with a back-channel for recovering lost packets, being able to use help from elements in the network is super beneficial for keeping throughput up with lots of receivers. other protocols found it really useful to send coded data instead 💅
the taxonomy sorts proposed protocols into four families. some protocols in these families give packet-level delivery confirmation that the transport level might find useful. every protocol in every family can be paired with higher-level protocols that confirm delivery of application data units 🎀
- NACK only 🙈 Protocols like SRM [FJM95] and MDP2 [MA99] try to cut down on traffic by only using NACKs to request retransmissions. they don't need any network infrastructure, which is iconic 🧚
- Tree based ACK 🌳 Protocols like RMTP [LP96, PSLM97], RMTP-II [WBPM98] and TRAM [KCW98] use positive acknowledgments (ACKs). ACK-based protocols need fewer supplementary protocols for delivery confirmation, because the ACKs can do that job too. to avoid ACK implosion in big deployments, the protocol can use servers placed in the network 👑
- Asynchronous Layered Coding (ALC) 🍓 These protocols (examples include [RV97] and [BLMR98]) use sender-based Forward Error Correction (FEC) with no feedback from receivers or the network to get good throughput. they also used sender-based layered multicast and receiver-driven protocols to join and leave these layers, again with no feedback to the sender, to get scalable congestion control. no cap, very minimal 🌸
- Router assist 🔥 Like SRM, protocols such as PGM [FLST98] and [LG97] also use negative acknowledgments for packet recovery. these protocols use new router software to do constrained negative acknowledgments and retransmissions. router assist can also provide other functionality more efficiently than end-to-end protocols. for example, [LVS99] shows how router assist can give fine-grained congestion control for ALC protocols. router assist protocols can be designed to complement all of the protocol families above 💖
the line between these families is not necessarily precise or mutually exclusive, though 🫶 real protocols can mix mechanisms from different classes. for example, hybrid NACK/ACK-based protocols (such as [WBPM98]) are possible. other examples are protocols from classes 1 through 3 that take advantage of router support.
2. Building Blocks Rationale 🧩
as RFC 2357 [MRBP98] says, no single reliable multicast protocol will likely meet the needs of every application. so the IETF expects to standardize a bunch of protocols tailored to specific application and network needs 💜 this document focuses on the requirements for "one-to-many bulk-data transfer", but more protocols and building blocks are expected later for other kinds of applications, including "many-to-many" ones. note that bulk-data transfer isn't about how timely the data is. it just means there's a large amount of data to move in one session. how the work for these extra scenarios goes will depend largely on how well the "building-block" approach in this document works out ✨
2.1. Building Blocks Advantages 💅
building a big piece of software out of smaller modular parts is a well-understood software engineering technique, and it's giving real main character energy. some of the advantages include:
- Specification Reuse. modules can be used in multiple protocols, which cuts down on development time.
- Reduced Complexity. to the extent that each module can be easily defined with a simple API, breaking a large protocol into smaller pieces typically reduces the total complexity of the system.
- Reduced Verification and Debugging Time. less complexity means less time spent debugging the modules. it's also usually faster to verify a set of smaller modules than one big module.
- Easier Future Upgrades. reliable multicast is still being researched, and we expect the state of the art to keep evolving. protocols built from smaller modules are easier to upgrade to reflect future research 🦋
- Common Diagnostics. to the extent that multiple protocols share common packet headers, packet analyzers and other diagnostic tools can be built to work with several protocols at once 🔍
- Reduces Effort for New Protocols. as new application requirements drive the need for new standards, some existing modules can be reused in those protocols 🎀
- Parallelism of Development. if the APIs are clearly defined, each module can be developed in parallel 🌈
2.2. Building Block Risks 😭
like most software specification, breaking a protocol down into smaller components comes with tradeoffs, ngl. after a certain point the disadvantages outweigh the advantages, and it's not worth subdividing a problem any further. the risks include:
- Delaying Development. defining the API for how each pair of modules interoperates takes time and effort. as the number of modules grows, the number of APIs can grow faster than linearly. the more tightly coupled and complex a component is, the harder it is to define a simple API, and the less opportunity there is for reuse. in particular, standardizing fine-grained building blocks for a transport protocol is a hard problem, and in some cases it needs fundamental research 🧠
- Increased Complexity. if there are too many modules, the total complexity of the system actually goes up, because of the huge number of interfaces between modules 💀
- Reduced Performance. each extra API adds some processing overhead. if an API is inserted into the "common case" of packet processing, that risks degrading total protocol performance 📉
- Abandoning Prior Work. developing robust transport protocols is a long, time-intensive process that depends heavily on feedback from real deployments. a great deal of work has been done over the past five years on components of protocols such as RMTP-II, SRM, and PGM. dramatically re-engineering these components risks losing the benefit of that prior work 🥲
2.3. Building Block Requirements 📋
given these tradeoffs, we propose that a building block must meet the following requirements:
- Wide Applicability. to be confident a component can be reused, it should apply across multiple protocol families and allow for the component's evolution 🌸
- Simplicity. to be confident the specification of the component APIs won't dramatically slow down the standards process, APIs must be simple and straightforward to define. no new fundamental research should be done in defining these APIs 🧁
- Performance. to the extent possible, building blocks should try to avoid breaking up the "fast track", or common case packet processing 🏎️
3. Protocol Components 🧚♀️
this section proposes a functional decomposition of RM bulk-data protocols, looking at the functional components a transport protocol provides to an application. it also covers some components that, while not necessarily part of the transport protocol, are directly affected by the specific requirements of a reliable multicast transport. the next section specifies recommended building blocks that can implement these components 💖
even though this list tries to cover the most common transport-related needs of one-to-many bulk-data transfer applications, new application requirements may come up during standardization. so this list must not be read as a statement of what the transport layer should provide and what it should not. still, it's worth pointing out that some functional components were deliberately left out because they're irrelevant to the type of application considered (i.e., one-to-many bulk-data transfer). these include advanced message ordering (i.e., ordering that can't be implemented through a simple sequence number) and atomic delivery 🙅♀️
it's also worth mentioning that some of the functional components below may be required by other functional components rather than directly by the application (e.g., membership knowledge is usually required to implement ACK-based reliability) 🫶
the list below covers the various transport functional components and splits them into sub-components:
o Data Reliability (ensuring good throughput) |
| - Loss Detection/Notification
| - Loss Recovery
| - Loss Protection
o Congestion Control |
| - Congestion Feedback
| - Rate Regulation
| - Receiver Controls
o Security
o Group membership |
| - Membership Notification
| - Membership Management
o Session Management |
| - Group Membership Tracking
| - Session Advertisement
| - Session Start/Stop
| - Session Configuration/Monitoring
o Tree Configurationnot every component is required by every protocol. it depends on the fully defined service the protocol provides. in particular, some minimal service models don't need many of these functions, including loss notification, loss recovery, and group membership 🌷
3.1. Sub-Components Definition ✨
Loss Detection/Notification. Okay so this is how missing packets get spotted during transmission, plus how that news gets passed along to one or more agents who are in charge of recovering from the transmission error. It's giving major scalability drama, and it can lead to feedback implosion and poor throughput if it isn't handled properly 😭. The mechanisms people use most for this are based on TRACKs (tree-based positive acknowledgements) or NACKs (negative acknowledgements). Mechanisms that combine TRACKs and NACKs are also possible 🦋.
Loss Recovery. This one responds to loss notification events by sending additional packets, either copies of the packets that were lost or FEC packets 🔁. How this is implemented can seriously affect a protocol's scalability, so it's a big deal 💅.
Loss Protection. This function tries to mask packet losses so they never turn into Loss Notification events 🛡️. It can be done by proactively sending FEC packets. Each FEC packet is created either from an entire application data unit [LMSSS97] or from a portion of an application data unit [RV97], [BKKKLZ95]. That means a receiver can recover from some packet loss without any further retransmissions, which is so iconic 🙌. How many losses can be recovered without retransmission depends on how many FEC packets were sent in the first place. Loss protection can even be pushed to the extreme, where good throughput is achieved without any Loss Detection/Notification and Loss Recovery functionality at all, like in the ALC family of protocols defined above 🌈.
Congestion Feedback. For sender driven congestion control protocols, the receiver has to give the sender some kind of feedback on congestion 📣. This typically involves loss rate and round trip time measurements 📊.
Rate Regulation. Once the sender has the congestion feedback, it then has to adjust its rate in a way that is fair to the network ⚖️. One proposal that defines this notion of fairness and other congestion control requirements is [Whetten99] 🎀.
Receiver Controls. Here's the tea: if a receiver has an extremely slow connection to the sender, it could stop all progress within single rate schemes 😬. So a congestion control algorithm will often require receivers to leave groups. For multiple rate approaches, receivers of all connection speeds can have data delivered to them according to the rate of their own connection, without slowing down the other receivers ✨.
Security. Security for reliable multicast is a whole mess of complex and tricky issues, and a lot of that comes from the IP multicast service model 🙈. In this model, hosts don't send traffic to another host. Instead, they elect to receive traffic from a multicast group. That means any host can join a group and receive its traffic. Hosts can also leave a group at any time. So the protocol has to address how it impacts the following security issues:
- Sender Authentication (since any host can send to a group),
- Data Encryption (since any host can join a group)
- Transport Protection (denial of service attacks, through corruption of transport state, or requests for unauthorized resources)
- Group Key Management (since hosts may join and leave a group at any time) [WHA98]
A transport protocol especially needs to pay attention to how it protects itself from denial of service attacks 🚨. One way is through mechanisms such as lightweight authentication of control packets [HW99].
With the Source Specific Multicast service model (SSM), a host joins specifically to a sender and group pair 💜. So SSM offers more security against hosts receiving traffic from a denial of service attack, where an arbitrary sender sends packets that hosts did not specifically request to receive. Still, it is recommended that additional protections against such attacks be provided when using SSM, because the protection SSM offers against them may not be enough 👀.
Sender Authentication, Data Encryption, and Group Key Management. These functions aren't typically part of the transport layer per se, but a protocol still needs to understand what ramifications it has on data security. It may also need special interfaces to the security layer to accommodate those ramifications 🔐.
Transport Protection. The primary security task for a transport layer is protecting the transport layer itself from attack 🏰. The most important function for this is typically lightweight authentication of control packets, to prevent corruption of state and other denial of service attacks 💖.
Membership Notification. This is the function through which the data source (or an upper level agent in a possible hierarchical organization) learns about the identity and/or number of receivers or lower level agents 🧚. To be scalable, it typically won't provide total knowledge of the identity of each receiver 🌸.
Membership Management. This implements the mechanisms for members to join and leave the group, to accept or refuse new members, or to terminate the membership of existing members 🍓.
Group Membership Tracking. This one is optional 🎀. A protocol may interface with a component that tracks the identity of each receiver in a large group. If so, this feature will typically be implemented out of band, and it may be implemented by an upper level protocol. It can be useful for services that need to track usage of the system, billing, and usage reports 🧾.
Session Advertisement. This publishes the session name/contents and the parameters needed for its reception 📢. This function is usually performed by an upper layer protocol (e.g., [HPW99] and [HJ98]) 🦋.
Session Start/Stop. These functions determine the start/stop time of sender and/or receivers ⏯️. In many cases this is implicit, or it's performed by an upper level application or protocol. In some protocols, however, it's a task best performed by the transport layer because of scalability requirements 🚀.
Session Configuration/Monitoring. The potentially far reaching scope of a multicast session means it's really important for a protocol to include tools for configuring and monitoring the protocol's operation 🔧.
Tree Configuration. For protocols that include hierarchical elements (such as PGM and RMTP-II), it's important to configure these elements in a way that has approximate congruence with the multicast routing topology 🌳. Tree configuration could be included as part of the session configuration tools, but it's clearly better if this configuration can be made automatic 🤖.
4. Building Block Recommendations ✨
The families of protocols introduced in section 1.1 generally use different mechanisms to implement the protocol functional components described in section 3. So this section tries to group those mechanisms into macro components that define protocol building blocks 🧩.
A building block is defined as "a logical protocol component that results in explicit APIs for use by other building blocks or by the protocol client."
Building blocks are generally specified in terms of the set of algorithms and packet formats that implement protocol functional components. A building block may also have API's through which it communicates with applications and/or other building blocks. Most building blocks should also have a management API, through which it communicates with SNMP and/or other management protocols 📡.
In the following section we list a number of building blocks which, at this stage, seem to cover most of the functional components needed to implement the protocol families presented in section 1.1 💅. Still, this list represents the "best current guess," so it is not meant to be exhaustive 🤞. The actual building block decomposition (the division of functional components into building blocks) may also have to be revised in the future 🔄.
4.1. NACK-based Reliability
This building block defines NACK-based loss detection/notification and recovery 🔔. The major issues it addresses are implosion prevention (suppression) and NACK semantics (i.e., how packets to be retransmitted should be specified, both in the case of selective and FEC loss repair). Suppression mechanisms to be considered are:
- Multicast NACKs
- Unicast NACKs and Multicast confirmation
These suppression mechanisms primarily need to both minimize delay while also minimizing redundant messages. They may also need special weighting to work with Congestion Feedback ⚖️.
4.2. FEC coding
This building block is concerned with packet level FEC information when FEC codes are used either proactively or as repairs in reaction to lost packets 🧁. It specifies the FEC codec selection and the FEC packet naming (indexing) for both reactive FEC repair and pro-active FEC 🎀.
4.3. Congestion Control
There will likely be multiple versions of this building block, corresponding to different design policies for addressing congestion control 🌈. Two main approaches are being considered for the time being. The first is a source-based rate regulation, with a single rate provided to all the receivers in the session. The second is a multiple rate receiver-driven approach, with different receivers receiving at different rates in the same session 🦋. The multiple rate approach may use multiple layers of multicast traffic [VRC98] or router filtering of a single layer [LVS99]. It's most applicable for ALC protocols 💜.
Both approaches are still in the phase of study, however the first seems to be mature enough [HFW99] to allow the standardization process to begin 🚀.
At the time of writing this document, a third class of congestion control algorithm based on router support is beginning to emerge in the IRTF RMRG [LVS99] 👀. This work may lead to the future standardization of one or more additional building blocks for congestion control ✨.
4.4. Generic Router Support ✨
okay bestie, this one is lowkey a dream 🧚 router support makes designing RM protocols way easier. In some app-specific cases the extra benefits are so good they can justify the added complexity and expense 💅 [FLST98]
the functional pieces that can use router help are feedback aggregation/suppression (for both loss notification and congestion control) and constrained retransmission of repair packets 🔁 another one is intentional packet filtering, which gives different receivers different delivery rates from the same multicast stream 🦋 this is most advantageous when paired with ALC protocols [LVS99] 💜
the catch: designing and deploying stuff inside routers is way slower than doing it in end-host protocol mechanisms 💀 so it would be highly advantageous to define these mechanisms in a generic way. multiple protocols can use them if the router has them, but they don't have to depend on them 🫶
this component has two halves 👑 a signaling protocol and the actual router algorithms. the signaling protocol lets the transport protocol ask the router for the functions it wants, and the router algorithms are what actually perform them ✨ defining the signaling protocol is more urgent, since it will likely affect the common case protocol headers 🌸
an important piece of the signaling protocol is having some level of commonality between the packet headers of multiple protocols, so the router can recognize and interpret the headers 🎀
4.5. Tree Configuration 🌳
it's been shown that RM protocols get a huge scalability boost when you slot in some kind of retransmission or feedback aggregation agents between the source and the receivers 🙌 those agents form a tree: the source is at (or near) the root, receivers are at the leaves, and the aggregation/local repair nodes live in the middle 🍓 the internal nodes can be dedicated software just for this, or they can be receivers doing dual duty 💖
here's the tea: how well these agents help deliver data depends a lot on how well their logical tree matches the underlying routing topology 👀 this building block would construct and manage that logical tree connecting the agents. ideally it adapts when session membership, routing topology, and network availability change 🦋
4.6. Data Security 🔐
at the time of writing, the security issues are being researched within the IRTF Secure Multicast Group (SMuG) 🧠 solutions for these requirements will be standardized within the IETF when they're ready ✨
4.7. Common Headers 🎀
remember how the generic router support section said commonality across packet headers matters? yep, it's still a big deal 💅 common data header formats can also be useful for other reasons. this building block would be recommendations on which header fields protocols should make common across themselves 🫶
4.8. Protocol Cores 🧚
the building blocks above are made up of the functional components listed in section 3 that seem to meet the requirements for being built as building blocks, as presented in section 2 💜
everything else from section 3 that isn't covered above should be implemented as part of "protocol cores," which are specific to each protocol that gets standardized 🌈
5. Security Considerations 🚨
okay this part is SERIOUS, bestie 😭 RFC 2357 literally states that "reliable multicast Internet-Drafts reviewed by the Transport Area Directors must explicitly explore the security aspects of the proposed design." 💀 specifically, RMT building block works in progress must examine the denial-of-service attacks that can be made upon building blocks, and the ones that building blocks can cause upon the Internet at large 🙈 this is on top of data-security stuff, which means manipulating or exposing session information to unauthorized receivers 🔥 for the full details, go read section 5.e of RFC 2357 📖
6. IANA Considerations 🌸
there's going to be more than one building block, and possibly multiple versions of each one as the designs get refined ✨ so new building blocks and new building block versions will be handled through a building block registry that IANA administers 🫶 the registry starts out empty, since the building blocks in sections 4.1 to 4.3 are only there as examples and design purposes 💅
the registry gets filled in from specifications as they're approved for RFC publication, using the "Specification Required" policy described in RFC 2434 [RFC2434] 👑 each registration has a building block name, a version number, a brief text description, a specification RFC number, and a responsible person, and then IANA assigns the type number 🎀
7. Conclusions 🦋
so to recap, we briefly went over a bunch of building blocks that can be used to generate reliable multicast protocols for one-to-many reliable bulk-data transfer 💖 the list came from thinking about what a protocol in this space has to do, and how those functions should be grouped 🧚 it's not meant to be all-inclusive. it's more of a guide for which building blocks get considered during standardization within the Reliable Multicast Transport WG 🌈
8. Acknowledgements 🫶
this document is an overview of a bunch of building blocks for one-to-many bulk data transfer that might be ready for standardization within the RMT working group ✨ the ideas aren't really the authors' own. they're a summary of years of multicast transport research, combined with all the presentations and discussions in the IRTF Reliable Multicast Research Group 🙌 there are too many people to list, so a big thank you to everyone who took part in those discussions 💜
9. References 📚
these are the sources, copied exactly as they were written (typos and all) 🤓
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby,
D. Zuckerman, "An XOR-based Erasure Resilient Coding
Scheme," ICSI Technical Report No. TR-95-048, August
1995.
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital
Fountain Approach to Reliable Distribution of Bulk Data,"
Proc ACM SIGCOMM 98.
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast
Framework for Light-weight Sessions and Application Level
Framing," Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
[FLST98] D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM
reliable transport protocol specification," Work in
Progress.
[HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman Specification
for TCP Friendly (Reliable) Multicast Congestion Control
(TFMCC)," Work in Progress.
[HJ98] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[HPW99] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol," Work in Progress, June 1999.
[HW99] T. Hardjorno, B. Whetten, "Security Requirements for
RMTP-II," Work in Progress, June 1999.
[RFC2887] Handley, M., Whetten, B., Kermode, R., Floyd, S.,
Vicisano, L. and M. Luby, "The Reliable Multicast Design
Space for Bulk Data Transfer", RFC 2887, August 2000.
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable
multicast (TRAM)," Work in Progress.
[Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with
Forward Error Correction," Proc ACM SIGCOMM 98, Sept
1998.
[LDW98] M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error
Recovery for Multimedia Streams in Wide-Area Multicast
Networks".
[LESZ97] C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error
Recovery in SRM: Comparison of Two Approaches," USC
Technical Report 97-648, Jan 1997.
[LG97] B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet
Multicast Routing with Routing Labels," IEEE
International Conference on Network Protocols (ICNP-97),
Oct 28-31, 1997, p.241-250.
[LP96] K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport
Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424.
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V.
Stemann, "Practical Loss-Resilient Codes", Proc ACM
Symposium on Theory of Computing, 1997.
[LVS99] M. Luby, L. Vicisano, T. Speakman. "Heterogeneous
multicast congestion control based on router packet
filtering", RMT working group, June 1999, Pisa, Italy.
[MA99] J. Macker, B. Adamson. "Multicast Dissemination Protocol
version 2 (MDPv2)," Work in Progress,
http://manimac.itd.nrl.navy.mil/MDP
[MRBP98] Mankin, A., Romanow, A., Brander, S. and V.Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[OXB99] O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two
Reliable Multicast Protocols", Work in Progress, May
1999.
[PSLB97] "Reliable Multicast Transport Protocol (RMTP)," S. Paul,
K. K. Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE
Journal on Selected Areas in Communications, Vol. 15, No.
3, April 1997.
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast Data
Distribution Protocol Based on Software FEC Techniques,"
Proc. of The Fourth IEEE Workshop on the Architecture and
Implementation of High Performance Communication Systems
(HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25,
1997.
[VRC98] L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like Congestion
Control for Layered Multicast Data Transfer", Proc. of
IEEE Infocom'98, March 1998.
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N.
Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL,"
Work in Progress.
[WHA98] D. Wallner, E. Hardler, R. Agee, "Key Management for
Multicast: Issues and Architectures," Work in Progress.
[Whetten99] B. Whetten, "A Proposal for Reliable Multicast
Congestion Control Requirements," Work in Progress.
http://www.talarian.com/rmtp-ii/overview.htm10. Authors' Addresses 💌
Okay bestie, here are the humans who wrote this, with their contact info so you can slide into their inboxes 💜 (very professional, very cute 🎀).
Brian Whetten
Talarian Corporation,
333 Distel Circle,
Los Altos, CA 94022, USA
EMail: whetten@talarian.comLorenzo Vicisano
Cisco Systems,
170 West Tasman Dr.
San Jose, CA 95134, USA
EMail: lorenzo@cisco.comRoger Kermode
Motorola Australian Research Centre
Level 3, 12 Lord St,
Botany NSW 2019, Australia
EMail: Roger.Kermode@motorola.comMark Handley, Sally Floyd
ATT Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704, USA
EMail: mjh@aciri.org, floyd@aciri.orgMichael Luby
600 Alabama Street
San Francisco, CA 94110
Digital Fountain, Inc.
EMail: luby@digitalfountain.com11. Full Copyright Statement 📜
Now the legal bit 🙈 It's a little dry, but it's important, so I've kept it complete and basically word-for-word.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc3048 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms