RFC 3450

Asynchronous Layered Coding (ALC) Protocol Instantiation

📅 published December 2002, from ietf

RFC 3450: Asynchronous Layered Coding (ALC) Protocol Instantiation ✨

okay so this is RFC 3450, the spec for Asynchronous Layered Coding (ALC) 🦋 It's from the IETF Network Working Group, dated December 2002, and it's an Experimental doc, which means it's a protocol being tested, not an official standard yet 🧪 The authors are M. Luby (Digital Fountain), J. Gemmell (Microsoft), L. Vicisano (Cisco), L. Rizzo (Univ. Pisa) and J. Crowcroft (Cambridge Univ.) 👑 The title block doesn't list anything this one obsoletes or updates, so it stands on its own 💅

Status of this Memo 📜

okay the status bit is important bestie 🫶 This memo defines an Experimental Protocol for the Internet community, and it does not specify an Internet standard of any kind. They're asking for discussion and suggestions for improvement, and the memo can be distributed freely 💌

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌸

ALC is a massively scalable reliable content delivery protocol 🚀 It's built from three building blocks: the Layered Coding Transport (LCT) one, a multiple rate congestion control one, and the Forward Error Correction (FEC) one. Put together, they deliver content reliably and asynchronously, with congestion control, to an unlimited number of concurrent receivers coming from a single sender 😭🔥

Table of Contents 🗂️

   1. Introduction.................................................2
     1.1 Delivery service models...................................3
     1.2 Scalability...............................................5
     1.3 Environmental Requirements and Considerations.............6
   2. Architecture Definition......................................8
     2.1 LCT building block........................................9
     2.2 Multiple rate congestion control building block..........10
     2.3 FEC building block.......................................11
     2.4 Session Description......................................13
     2.5 Packet authentication building block.....................14
   3. Conformance Statement.......................................14
   4. Functionality Definition....................................14
     4.1 Packet format used by ALC................................15
     4.2 Detailed Example of Packet format used by ALC............16
     4.3 Header-Extension Fields..................................23
     4.4 Sender Operation.........................................26
     4.5 Receiver Operation.......................................27
   5. Security Considerations.....................................29
   6. IANA Considerations.........................................31
   7. Intellectual Property Issues................................31
   8. Acknowledgments.............................................31
   9. References..................................................31
   Authors' Addresses.............................................33
   Full Copyright Statement.......................................34

1. Introduction 💖

okay so ALC is a massively scalable reliable content delivery protocol 🌈 It runs multiple rate congestion controlled reliable content delivery, and it's designed for massive scale over IP multicast as the underlying network service 🚀 "Massive" here is no joke: the number of concurrent receivers for one object can reach the millions 🤯 The total size of the objects in a session can range from hundreds of kilobytes to hundreds of gigabytes 📦 Every receiver can start grabbing an object asynchronously, its reception rate is the maximum fair bandwidth between it and the sender, and a single sender can handle all of that 👑

Because ALC is all about reliable content delivery, the goal is to get objects to each receiver as fast as possible, while still being network friendly to competing traffic 🫶 So the congestion control used with ALC should strive to use as much of the available bandwidth between receivers and the sender as it can, while backing off aggressively when there's competing traffic 🦋

The sender side of ALC generates packets from the objects being delivered in the session, then sends the formatted packets at the right rates to the channels tied to the session 📤 The receiver side joins the right channels, does congestion control by adjusting which joined channels it's on when it detects congestion, and uses the packets to rebuild objects reliably 🧩 All the information in an ALC session flows as data packets from one sender to the channels receivers join 💜

ALC does specify the Session Description that receivers need before they join a session, but how receivers actually get that info is outside the scope of ALC 🙈 An application using ALC might want receivers to report their reception stats back to the sender, and how they do that is also outside the scope of ALC 💅 In general, ALC is meant to be a minimal protocol instantiation that gives reliable delivery without adding unnecessary limits on the scalability of the basic protocol ✨

This document is a product of the IETF RMT WG and follows the general guidelines from RFC 3269 [8]. 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2] 📚

Statement of Intent 🔥

This memo has part of the definitions you need to fully specify a Reliable Multicast Transport protocol, following RFC2357 🧠 And as RFC2357 says, using any reliable multicast protocol on the Internet requires an adequate congestion control scheme 🚨

Until that kind of scheme is available, or until an existing one is proven adequate, the Reliable Multicast Transport working group (RMT) is publishing this Request for Comments in the "Experimental" category 🧪

RMT intends to resubmit this spec as an IETF Proposed Standard as soon as that condition is met 🏆

1.1 Delivery service models 🎀

ALC can support several different reliable content delivery service models 💖 A few examples are described briefly here 🌸

Push service model 📤

A push model is a sender-initiated concurrent delivery of objects to a selected set of receivers 💌 It could be used for something like reliably delivering a huge object, say a 100 GB file 🧚 The sender could send a Session Description announcement to a control channel, and receivers could watch that channel and join a session whenever a Session Description they care about shows up 👀 Once a receiver gets the Session Description, it could join the session and keep receiving packets until it has enough to reconstruct the object, then report back to the sender that reception finished successfully ✅ The sender could keep sending packets for the object to the session until all receivers have reported successful reconstruction, or until some other condition is met 🔁 In this example, the sender uses ALC to generate packets from the object and send them to the channels for the session, and the receivers use ALC to receive packets from the session and rebuild the object 🦋

There are several features ALC gives you for the push model 💅 For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header. The ERT says how much time is left for packet transmission, either for the single object in the session or for the object identified by the Transmission Object Identifier (TOI) if the session carries several objects ⏳ Receivers can use that to figure out whether there's enough time left to receive enough additional packets to recover the object 🫣 If there isn't enough time, the push application might have receivers report back to the sender so it extends the transmission for long enough that receivers can get enough packets to rebuild the object 📈 The sender could then include an ERT based on that extended transmission time in each later packet header for the object 🔮

Other examples: the LCT header can optionally contain a Close Session flag, which says when the sender is about to stop sending packets to the session, and a Close Object flag, which says when the sender is about to stop sending packets for the object identified by the Transmission Object ID 🚪 But these flags aren't completely reliable, so the Close Session flag should only be used as a hint for when the session is about to close, and the Close Object flag should only be used as a hint for when packet transmission for the object is about to end 🙈

Heads up bestie: these flags are hints, not guarantees. Don't bet your whole session on them 💀

The push model is especially attractive in satellite and wireless networks 🛰️ In those environments a session might have just one channel, and a sender might send packets at a fixed rate to that channel. Sending at a fixed rate without congestion control is outside the scope of this document 🚫

On-demand content delivery model 🌙

For an on-demand service model, senders usually transmit for some time period picked to be long enough that all the intended receivers can join the session and recover a single object 🕰️ For example, a popular software update might get transmitted with ALC for several days, even though a receiver might finish the download in just one hour of total connection time, possibly spread across several intervals 🍓 In this case, receivers can join the session at any point while it's active, and they leave once they've received enough packets to recover the object 🏃‍♀️ Receivers get the Session Description by contacting a web server 🌐

Other service models 🦄

There may be other reliable content delivery service models that ALC can support 🌈 Describing those potential applications, the right delivery service model, and any extra mechanisms needed to support those functions alongside ALC is beyond the scope of this document 🙌

That's the end of part 1, bestie. Part 2 is coming next! 🌈✨

1.2 Scalability

okay so massive scalability is literally the main goal for ALC 💖 IP multicast is already super scalable, but the best effort service it gives you has no session management, no congestion control, and no reliability 😭 ALC adds all of that on top of IP multicast without giving up any of that scalability. the vibes ALC gives off:

  • to each receiver, it feels like they have their own dedicated session from the sender, and the reception rate adjusts to congestion along the path from sender to receiver 🦋
  • to the sender, there is no difference in load or outgoing rate whether one receiver has joined or a million (or any number of) receivers have joined, no matter when they join or leave 🌸
  • no feedback packets are required from receivers to the sender 🫶
  • almost all packets in the session that go through a bottleneck link get used by downstream receivers, and the session shares the link fairly with competing flows in proportion to their utility 👑

so ALC is a massively scalable content delivery transport that is network friendly, periodt 💅

ALC intentionally leaves out any application specific features that could limit its scalability ✨ that's how it stays a minimal protocol that scales massively. applications can be built on top of ALC to add extra features, and those features might limit the application's scalability. those applications are outside the scope of this document 🧚

1.3 Environmental Requirements and Considerations

so every environmental requirement and consideration that applies to the LCT building block [11], the FEC building block [10], the multiple rate congestion control building block, and any additional building blocks ALC uses also applies to ALC 🎀

ALC requires connectivity from a sender to receivers, but it does not require connectivity from receivers back to a sender 🦋 it inherently works with all types of networks: LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks 🌈 so the inherent raw scalability of ALC is unlimited ✨ BUT (lowercase, not a keyword, just vibes) receivers need to get the Session Description out-of-band before joining a session, and some implementations of that may limit scalability 🙈

if a receiver is joined to multiple ALC sessions, it MUST be able to uniquely identify and demultiplex packets to the correct session. the Transmission Session Identifier (TSI) that MUST appear in each packet header is what handles this 🔥 the TSI is scoped by the IP address of the sender, and the sender's IP address together with the TSI uniquely identify the session. so the demultiplexing MUST be done based on the IP address of the sender and the TSI of the session from that sender 💜

ALC is presumed to be used with an underlying IP multicast network or transport service that is a "best effort" service. that means it does not guarantee packet reception or packet reception order, and it has no support for flow or congestion control 💀 there are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in RFC 1112 [3], and the Source-Specific Multicast (SSM) model as defined in [7]. ALC works with both models, but in slightly different ways with somewhat different environmental concerns 🍓

with ASM, a sender S sends packets to a multicast group G, and an ALC channel address is the pair (S,G), where S is the IP address of the sender and G is a multicast group address 🌸 with SSM, a sender S sends packets to an SSM channel (S,G), and the ALC channel address is exactly the same as the SSM channel address ✨

a sender can locally allocate unique SSM channel addresses, which makes allocating ALC channel addresses easy with SSM 🎀 to allocate ALC channel addresses using ASM, the sender must uniquely choose the ASM multicast group address across the scope of the group, and that makes allocation harder with ASM 😭

ALC channels and SSM channels coincide, so the receiver will only receive packets sent to the requested ALC channel 🦋 with ASM, the receiver joins an ALC channel by joining a multicast group G, and then all packets sent to G may be received by the receiver, no matter who the sender is 🙈 that's why SSM has compelling security advantages over ASM for preventing denial of service attacks 🔥 in either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources 🫶

there are other ASM specific issues with how the multiple rate congestion control building block interacts with ASM 🧚 the congestion control building block may use the measured difference in time between when a join to a channel is sent and when the first packet from that channel arrives to determine the receiver reception rate. it may also use packet sequence numbers per channel to measure losses, which also feeds into the receiver reception rate 🌈 these two features raise two concerns with ASM. first, the time difference between sending the join and the first packet arriving can be significant because of Rendezvous Points (RPs) and the MSDP protocol. second, packets can be lost during the switchover from the (*,G) join to the RP to the (S,G) join directly to the sender 💀 both of these issues could seriously degrade the reception rate of receivers. to help with these concerns, it is RECOMMENDED that the RP be as close to the sender as possible 🍓 SSM does not share these same concerns. for a fuller look at these issues, check out the multiple rate congestion control building block 💅

some networks don't play nicely with some congestion control protocols that could be used with ALC 😭 especially for a satellite or wireless network, receivers may have no way to effectively reduce their reception rate, because the session may have a fixed transmission rate allocated to it 🙈

ALC is compatible with either IPv4 or IPv6, since no part of the packet is IP version specific 🌸

2. Architecture Definition ✨

ALC uses the LCT building block [11] to provide in-band session management functionality 🎀 it uses a multiple rate congestion control building block that is compliant with RFC 2357 [12] to provide feedback free congestion control. receivers adjust their reception rates individually by joining and leaving the channels associated with the session 🦋 ALC uses the FEC building block [10] to provide reliability. the sender generates encoding symbols based on the object to be delivered, using FEC codes, and sends them in packets to the channels associated with the session 🌈 receivers just wait for enough packets to arrive so they can reliably reconstruct the object 🫶 so there is no request for retransmission of individual packets from receivers that miss packets to ensure reliable reception of an object 👑 and the packets, plus their rate of transmission out of the sender, can be independent of the number of receivers and each receiver's individual reception experience 💅

the definition of a session for ALC is the same as it is for LCT 💖 an ALC session is made up of multiple channels originating from a single sender, used for some period of time to carry packets relating to the transmission of one or more objects that might interest receivers ✨ congestion control is performed over the aggregate of packets sent to the channels belonging to a session 🔥 the fact that an ALC session is limited to a single sender doesn't rule out receiving packets for the same objects from multiple senders 🧚 however, each sender would be sending packets to a different session, and congestion control is applied to each of those individually 💜 receiving from multiple sessions at the same time is allowed, but how that's done at the application level is outside the scope of this document 🙈

ALC is a protocol instantiation as defined in RFC 3048 [16] 🌸 this document describes version 1 of ALC, which MUST use version 1 of LCT described in [11] 🎀 like LCT, ALC is designed to be used with the IP multicast network service. this specification defines ALC as payload of the UDP transport protocol [15] that supports IP multicast delivery of packets 🦋 future versions of this specification, or companion documents, may extend ALC to use the IP network layer service directly 🌈 ALC could be used as the basis for designing a protocol that uses a different underlying network service, such as unicast UDP, but designing that protocol is outside the scope of this document 🧚

an ALC packet header comes right after the UDP header and consists of the default LCT header described in [11], followed by the FEC Payload ID described in [10] ✨ the Congestion Control Information field within the LCT header carries the required Congestion Control Information described in the multiple rate congestion control building block that is compliant with RFC 2357 [12] 💅 the packet payload that follows the ALC packet header consists of encoding symbols, which are identified by the FEC Payload ID as described in [10] 🫶

each receiver is required to obtain a Session Description before joining an ALC session 🔥 as described later, the Session Description includes the out-of-band information required by the LCT, FEC, and multiple rate congestion control building blocks 👑 the FEC Object Transmission Information specified in the FEC building block [10] that a receiver needs for each object it wants to receive can be communicated to the receiver either out-of-band or in-band using a Header Extension 💖 how the Session Description and the FEC Object Transmission Information get to a receiver is outside the scope of this document 😭

2.1. LCT building block ✨

Okay so LCT needs receivers to be able to uniquely identify and demultiplex packets tied to an LCT session, and ALC inherits and strengthens this requirement 💅. A Transport Session Identifier (TSI) MUST be associated with each session and MUST be carried in the LCT header of each ALC packet. The TSI is scoped by the sender IP address, and the (sender IP address, TSI) pair MUST uniquely identify the session 🦋.

The LCT header has a Congestion Control Information (CCI) field that MUST be used to carry the Congestion Control Information from the specified multiple rate congestion control protocol. There's also a field in the LCT header that says how long the CCI field is, and the multiple rate congestion control building block MUST uniquely identify a format of the CCI field that matches that length 🎀.

The LCT header also has a Codepoint field that MAY be used to tell a receiver the settings for info that might change during a session 🌸. If it's used, the mapping between settings and Codepoint values is to be communicated in the Session Description, and that mapping is outside the scope of this document. For example, the FEC Encoding ID that's part of the FEC Object Transmission Information (as specified in the FEC building block [10]) could vary for each object carried in the session, and the Codepoint value could be used to communicate the FEC Encoding ID to be used for each object. The mapping between FEC Encoding IDs and Codepoints could be, for example, the identity mapping ✨.

If more than one object is going to be carried within a session, then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets belong to which objects. In this case the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, which means the TOI is scoped by the session 🧚. The TOI for each object is REQUIRED to be unique within a session, but it MAY NOT be unique across sessions. Furthermore, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document 💜.

If only one object is carried within a session, then the TOI MAY be omitted from the LCT header 🍓.

The default LCT header from version 1 of the LCT building block [11] MUST be used. 👑

2.2. Multiple rate congestion control building block

Implementors of ALC MUST implement a multiple rate feedback-free congestion control building block that is in accordance with RFC 2357 [12]. Congestion control MUST be applied to all packets within a session, regardless of which object's information is carried in each packet 🔥. Multiple rate congestion control is specified because it scales massively and because it's really good for reliable content delivery 🌈. The multiple rate congestion control building block MUST specify in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header. It MAY specify more than one format, but it MUST specify at most one format for each of the possible lengths 32, 64, 96 or 128 bits 🦋.

The value of C in the LCT header, which determines the length of the CCI field, MUST correspond to one of the lengths for the CCI defined in the multiple rate congestion control building block. This length MUST be the same for all packets sent to a session, and the CCI format that corresponds to that length (as specified in the multiple rate congestion control building block) MUST be the format used for the CCI field in the LCT header 💅.

When a multiple rate congestion control building block is in use, a sender sends packets in the session to several channels at potentially different rates. Individual receivers then adjust their reception rate within a session by changing which set of channels they're joined to at each point in time, depending on the available bandwidth between the receiver and the sender, but independently of other receivers 🌸✨.

2.3. FEC building block

The FEC building block [10] provides reliable object delivery within an ALC session 🫶. Each object sent in the session is independently encoded using FEC codes as described in [9], which gives a deeper explanation of how FEC codes are used in reliable content delivery protocols 🧠. All packets in an ALC session MUST contain an FEC Payload ID in a format that complies with the FEC building block [10]. The FEC Payload ID uniquely identifies the encoding symbols that make up the payload of each packet, and the receiver MUST use the FEC Payload ID to determine how the encoding symbols carried in the payload of the packet were generated from the object, as described in the FEC building block 🔥.

As described in [10], a receiver is REQUIRED to obtain the FEC Object Transmission Information for each object whose data packets it receives from the session. The FEC Object Transmission Information includes:

  • The FEC Encoding ID.
  • If an Under-Specified FEC Encoding ID is used, then the FEC Instance ID associated with the FEC Encoding ID.
  • For each object in the session, the length of the object in bytes.
  • The additional required FEC Object Transmission Information for the FEC Encoding ID, as prescribed in the FEC building block [10]. For example, when the FEC Encoding ID is 128, the required FEC Object Transmission Information is the number of source blocks the object is partitioned into and the length of each source block in bytes 🍓.

Some of the FEC Object Transmission Information MAY be implicit, depending on the implementation. As an example, source block lengths may be derived by a fixed algorithm from the object length. As another example, it may be that all source blocks are the same length, and this is what's passed out-of-band to the receiver. As another example, the full-sized source block length might be provided, and that's the length used for all but the last source block, which is calculated from the full source block length and the object length. As one more example, the same FEC Encoding ID and FEC Instance ID may always be used for a particular application, so the FEC Encoding ID and FEC Instance ID are implicitly defined 🌈.

Sometimes the objects that will be sent in a session are completely known before the receiver joins the session, in which case the FEC Object Transmission Information for all objects in the session can be communicated to receivers before they join. Other times, objects may not be known when the session begins, receivers may join a session in progress and not be interested in some objects whose transmission has already finished, or receivers may leave a session before some objects are even available. In these cases, the FEC Object Transmission Information for each object may be dynamically communicated to receivers at or before the time packets for that object are received from the session. This may be accomplished using an out-of-band mechanism, in-band using the Codepoint field or a Header Extension, or any combination of these methods. How the FEC Object Transmission Information is communicated to receivers is outside the scope of this document 🧚.

If packets for more than one object are transmitted within a session, then a Transmission Object Identifier (TOI) that uniquely identifies objects within a session MUST appear in each packet header. Portions of the FEC Object Transmission Information could be the same for all objects in the session, in which case those portions can be communicated to the receiver with an indication that they apply to all objects in the session. These portions may be implicitly determined based on the application; for example, an application may use the same FEC Encoding ID for all objects in all sessions. If there's a portion of the FEC Object Transmission Information that may vary from object to object, and this information is communicated to a receiver out-of-band, then the TOI for the object MUST also be communicated to the receiver together with the corresponding FEC Object Transmission Information, and the receiver MUST use the corresponding FEC Object Transmission Information for all packets received with that TOI. How the TOI and corresponding FEC Object Transmission Information are communicated out-of-band to receivers is outside the scope of this document 💜.

It's also possible that a portion of the FEC Object Transmission Information that may vary from object to object is carried in-band, for example in the CodePoint field or in Header Extensions. How this is done is outside the scope of this document. In this case, the FEC Object Transmission Information is associated with the object identified by the TOI carried in the packet 👑✨.

2.4. Session Description ✨

okay so before a receiver can join an ALC session, it is REQUIRED to get the Session Description 💌 and it MUST contain all of this:

  • The multiple rate congestion control building block used for the session 🚦
  • The sender IP address 📍
  • The number of channels in the session 📻
  • The address and port number used for each channel 🔌
  • The Transport Session ID (TSI) for the session 🆔
  • Whether or not the session carries packets for more than one object 📦
  • If Header Extensions are going to be used, the format of those Header Extensions 🧩
  • Enough info to figure out the packet authentication scheme, if one is being used 🔐

how the Session Description actually reaches receivers is not this doc's job, so that part is out of scope 🙃

the Codepoint field in the LCT part of the header can be used to pass some of the dynamically changing info within a session, in-band 🪄 to make that work, a mapping between Codepoint values and the different dynamic settings MUST be included in the Session Description. then the settings to use just get communicated through the Codepoint value in each packet. it's giving efficiency 💅

for example, multiple objects might be delivered in the same session, and each type of object might use a different FEC encoding algorithm. so the Session Description could map Codepoint values to FEC Encoding IDs 🍓 another example: different packets sent to the session might use different packet authentication schemes. then the mapping between the authentication scheme and Codepoint values could go in the Session Description too 🔑 and you can even map combinations of settings to a single Codepoint value. like, one specific combo of a FEC Encoding ID and a packet authentication scheme could get its own Codepoint 🧁

the Session Description could also include, but is not limited to:

  • The mappings between combinations of settings and Codepoint values 🗺️
  • The data rates used for each channel 📈
  • The length of the packet payload 📏
  • Any info relevant to each object being transported, such as the Object Transmission Information for each object, when the object will be available within the session, and for how long ⏳

the Session Description could be in a form like SDP as defined in RFC 2327 [5] 🎀, or XML metadata as defined in RFC 3023 [13] 🧾, or HTTP/Mime headers as defined in RFC 2068 [4] 🌸, and so on. it might get carried in a session announcement protocol like SAP as defined in RFC 2974 [6] 📣, or come through some proprietary session control protocol 🔒, or live on a web page with scheduling info 🌐, or be sent over E-mail or other out-of-band methods 📬. talking about Session Description formats and how to send them to receivers is beyond the scope of this document, so we're leaving that one alone 🫶

2.5. Packet authentication building block 🛡️

it is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks 🔥 an example of a possibly suitable scheme is described in [14]. if you do use packet authentication in ALC, it gets integrated through the Header Extension support for packet authentication that the LCT building block provides 💜

3. Conformance Statement 📜

this Protocol Instantiation document, together with the LCT building block [11], the FEC building block [10], and a multiple rate congestion control building block, completely specifies a working reliable multicast transport protocol 👑 that conforms to the requirements described in RFC 2357 [12]. the whole squad has to show up for this to count 🫂

4. Functionality Definition ✨

this section is all about the format and functionality of the data packets carried in an ALC session, plus what the sender and receiver do during a session 🦋

4.1. Packet format used by ALC 📦

okay the packet format used by ALC is: the UDP header, then the default LCT header, then the FEC Payload ID, then the packet payload 💖 the default LCT header is described in the LCT building block [11], and the FEC Payload ID is described in the FEC building block [10]. the Congestion Control Information field in the LCT header holds the REQUIRED Congestion Control Information described by whichever multiple rate congestion control building block you're using 🚦 the packet payload contains encoding symbols generated from an object. if more than one object is carried in the session, the Transmission Object ID (TOI) in the LCT header MUST be used to identify which object the encoding symbols came from 🎯 inside the scope of an object, the encoding symbols in the payload are identified by the FEC Payload ID, as described in the FEC building block 🧩

the ALC version number in this document is 1 🌈 that matches version 1 of the LCT building block [11] used in this spec. the LCT version number field should be read as the ALC version number field ✨

here's the overall ALC packet picture, Figure 1 🖼️ it's an IP packet (IPv4 or IPv6), with the IP header sitting in front of the UDP header. the ALC packet format doesn't care which IP version you're on, so no drama 💅 the default LCT header MUST be used by ALC, and that default is described in detail in the LCT building block [11] 🫶

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         UDP header                            |
|                                                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                     Default LCT header                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       FEC Payload ID                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Encoding Symbol(s)                        |
|                           ...                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1 - Overall ALC packet format

sometimes an ALC sender needs to send packets with no payload at all 🫥 for example, to signal the end of a session or to convey congestion control information. these data-less packets don't carry the FEC Payload ID either, just the LCT header fields. the total datagram length, which the outer protocol headers (like the IP or UDP header) tell you, lets receivers spot that the ALC payload and FEC Payload ID are missing 🕵️‍♀️

4.2. Detailed Example of Packet format used by ALC 🔍

here's a detailed example of an ALC packet starting with the LCT header 🎀 in this example, the LCT header is the first 5 32-bit words, the FEC Payload ID is the next 2 32-bit words, and the rest of the packet is payload 💜

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   1   | 0 | 0 |1| 1 |0|1|0|0|0|       5       |      128      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Congestion Control Information (CCI, length = 32 bits)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Transport Session Identifier (TSI, length = 32 bits)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Transport Object Identifier (TOI, length = 32 bits)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sender Current Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Source Block Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Encoding Symbol ID                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Encoding Symbol(s)                         |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2 - A detailed example of the ALC packet format

the LCT part of the overall ALC packet header is variable size 📏 a length field in the third byte of the header tells you how big it is. all integer fields go in "big-endian" or "network order" format, meaning most significant byte (octet) first 🍑 bits marked "padding" or "reserved" (r) MUST be set to 0 by senders and ignored by receivers 🙈 unless noted otherwise, numeric constants in this spec are decimal (base 10) 🔢

here's what each field in this detailed example does and how long it is, in the order they show up in the header 🧚

ALC version number (V): 4 bits 🌸

this indicates the ALC version number. the ALC version number for this spec is 1, as shown here. it's also the LCT version number 💅

Congestion control flag (C): 2 bits 🚦

the Congestion Control Information (CCI) field defined by the multiple rate congestion control building block is a multiple of 32 bits long. the multiple rate congestion control building block MUST specify a format for the CCI 👑 it MAY specify formats for different CCI lengths, where the possible lengths are 32, 64, 96 or 128 bits. the value of C MUST match the length of exactly one of the possible formats for that building block, and that format MUST be used for the CCI field 🎯 the value of C MUST be the same for all packets sent to a session 🫶

  • C=0 means the 32-bit CCI field format is used 🍼
  • C=1 means the 64-bit CCI field format is used 🥤
  • C=2 means the 96-bit CCI field format is used 🍔
  • C=3 means the 128-bit CCI field format is used 🍕

in the example, C=0, so a 32-bit format is used ✨

Reserved (r): 2 bits 🫥

reserved for future use. a sender MUST set these bits to zero, and a receiver MUST ignore these bits 🤐 in the example, these bits are set to 0 🙃

Transport Session Identifier flag (S): 1 bit 🆔

this is the number of full 32-bit words in the TSI field. the TSI field is 32*S + 16*H bits long 📐 for ALC, the length of the TSI field is REQUIRED to be non-zero. that means S=0 and H=0 MUST NOT be used 🚫 in the example, S=1 and H=0, so the TSI is 32 bits long 💖

Transport Object Identifier flag (O): 2 bits 🎀

this is the number of full 32-bit words in the TOI field. the TOI field is 32*O + 16*H bits long 🧮 if more than one object is going to be delivered in the session, the TOI MUST be used, and in that case O=0 and H=0 MUST NOT be used 🙅‍♀️

In the example O=1 and H=0, so the TOI is 32-bits long 🧚

Half-word flag (H): 1 bit 🎀

Okay so the TSI and TOI fields are each a multiple of 32-bits plus 16*H bits long. This lets their lengths be multiples of a half-word (16 bits), while the aggregate length of the TSI and TOI fields still comes out to a multiple of 32-bits 💅

In the example H=0, which means both TSI and TOI are multiples of 32-bits in length.

Sender Current Time present flag (T): 1 bit ⏰

T = 0 means the Sender Current Time (SCT) field is not present. T = 1 means the SCT field is present. Senders put the SCT in to tell receivers how long the session has been going, so it's basically a session timer 🌸

In the example T=1, so the SCT is carried in this packet.

Expected Residual Time present flag (R): 1 bit 🦋

R = 0 means the Expected Residual Time (ERT) field is not present. R = 1 means the ERT field is present.

Senders use the ERT to tell receivers how much longer packets are going to be sent to the session. That's either for the single object carried in the session, or for the object identified by the TOI if there are multiple objects in the session 👀 Senders MUST NOT set R = 1 when the ERT for the object is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds. That's a hard no, bestie 🙅‍♀️

In the example R=0, so the ERT is not carried in this packet.

Close Session flag (A): 1 bit 🥺

Normally, A is set to 0. The sender MAY set A to 1 when termination of transmission of packets for the session is imminent. A MAY be set to 1 in just the last packet transmitted for the session, or A MAY be set to 1 in the last few seconds of packets transmitted for the session. Once the sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1 tells a receiver that the sender is about to immediately stop sending packets for the session. When a receiver gets a packet with A set to 1, the receiver SHOULD assume that no more packets will be sent to the session. It's giving goodbye 👋✨

In the example A=0, so this packet does not signal that the session is closing.

Close Object flag (B): 1 bit 📦

Normally, B is set to 0. The sender MAY set B to 1 when termination of transmission of packets for an object is imminent. If the TOI field is in use and B is set to 1, then termination of transmission for the object identified by the TOI field is imminent. If the TOI field is not in use and B is set to 1, then termination of transmission for the one object in the session identified by out-of-band information is imminent. B MAY be set to 1 in just the last packet transmitted for the object, or B MAY be set to 1 in the last few seconds of packets transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of transmission of packets for the object. A received packet with B set to 1 tells a receiver that the sender is about to immediately stop sending packets for the object. When a receiver gets a packet with B set to 1, it SHOULD assume that no more packets will be sent for the object to the session. Object-level closure, iykyk 💅

In the example B=0, so this packet does not mark the end of sending data packets for the object.

LCT header length (HDR_LEN): 8 bits 📏

This is the total length of the LCT header in units of 32-bit words. The length of the LCT header MUST be a multiple of 32-bits. This field can be used to jump straight to the part of the packet beyond the LCT header, so either the FEC Payload ID (if the packet has a payload) or the end of the packet (if it has no payload) 🧭

In the example, HDR_LEN=5, so the LCT header portion of the overall ALC is 5 32-bit words.

Codepoint (CP): 8 bits 🍓

ALC uses this field to carry a mapping that identifies the settings for the parts of the Session Description that can change within the session. The mapping between Codepoint values and those settings is communicated out-of-band.

In the example, the part of the Session Description that can change within the session is the FEC Encoding ID, and the identity mapping is used between Codepoint values and FEC Encoding IDs. So CP=128 identifies FEC Encoding ID 128, the "Small Block, Large Block and Expandable FEC Codes" described in the FEC building block [10]. The FEC Payload ID associated with FEC Encoding ID 128 is 64-bits long 🔥

Congestion Control Information (CCI): 32, 64, 96 or 128 bits 🌈

This field contains the Congestion Control Information defined by the multiple rate congestion control building block. The format of this field is determined by that building block.

This field MUST be 32 bits if C=0. This field MUST be 64 bits if C=1. This field MUST be 96 bits if C=2. This field MUST be 128 bits if C=3.

In the example, the CCI is 32-bits long. The format of the CCI field for the example MUST correspond to the format for the 32-bit version of the CCI specified in the multiple rate congestion control building block 🎯

Transport Session Identifier (TSI): 16, 32 or 48 bits 🪪

The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the sender IP address, so the (sender IP address, TSI) pair uniquely identifies the session. For ALC, the TSI MUST be included in the LCT header.

The TSI MUST be unique among all sessions served by the sender while the session is active, and for a long stretch of time before and after it's active. Its main job is to stop receivers from accidentally accepting packets that belong to sessions they didn't sign up for 🙈 Picture this: a session gets deactivated, then the sender activates a different session that uses an overlapping set of channels. A receiver that stayed connected to the first session during that switch could mistake packets from the second session for the first one, but only if the two TSIs were identical. Mapping TSI values to sessions is outside the scope of this document and is done out-of-band.

The length of the TSI field is 32*S + 16*H bits. The aggregate length of the TSI field plus the TOI field is a multiple of 32 bits.

In the example, the TSI is 32 bits long.

Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits. 🗂️

This field says which object in the session this packet is about. For example, a sender might send several files in the same session, using TOI=0 for the first file, TOI=1 for the second, and so on. The TOI could also be a unique global identifier for an object being sent from several senders at once, where the TOI value is the output of a hash function applied to the object. Mapping TOI values to objects is outside the scope of this document and is done out-of-band. The TOI field MUST be used in all packets if more than one object is going to be transmitted in a session. In other words, the TOI field is either present in all the packets of a session or never present at all 🫶

The length of the TOI field is 32*O + 16*H bits. The aggregate length of the TSI field plus the TOI field is a multiple of 32 bits.

In the example, the TOI is 32 bits long.

Sender Current Time (SCT): 0 or 32 bits ⏳

This field holds the sender's current clock at the moment this packet was sent. It's measured in units of 1ms and computed modulo 2^32 units from the start of the session.

This field MUST NOT be present if T=0, and MUST be present if T=1.

In this example, the SCT is present.

Expected Residual Time (ERT): 0 or 32 bits ⌛

This field holds the sender's expected residual transmission time for packets, either for the single object carried in the session or for the object identified by the TOI if there are multiple objects in the session.

This field MUST NOT be present if R=0, and MUST be present if R=1.

In this example, the ERT is not present.

FEC Payload ID: X bits 🧩

The length and format of the FEC Payload ID depend on the FEC Encoding ID, as described in the FEC building block [10]. The FEC Payload ID format is determined by the FEC Encoding ID, which MUST be communicated in the Session Description. The Session Description MAY specify that more than one FEC Encoding ID is used in the session. If it does, the Session Description MUST contain a mapping that identifies which Codepoint values correspond to which FEC Encoding IDs. This mapping, if used, is outside the scope of this document.

The example packet format matches the format for "Small Block, Large Block and Expandable FEC Codes" described in the FEC building block, which has FEC Encoding ID 128. For FEC Encoding ID 128, the FEC Payload ID consists of the following two fields, which add up to X = 64 bits in total:

Source Block Number (SBN): 32 bits 🍰

The Source Block Number identifies which source block of the object the encoding symbol(s) in the payload were generated from. The blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.

Encoding Symbol ID (ESI): 32 bits 💜

The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload depends on the particular encoding algorithm, which is identified by the FEC Encoding ID and the FEC Instance ID 🌟

Encoding Symbol(s): Y bits 🦄

Okay so the encoding symbols are what the receiver uses to rebuild an object 🧩 And the total length Y of the encoding symbol(s) in a packet? The receiver figures that out by taking the total length of the received packet and subtracting the length of the headers. Math, but make it cute 🎀

4.3. Header-Extension Fields ✨

Header Extensions let you extend the LCT header part of the ALC header to fit optional header fields that aren't always used, or that have a variable size 🦋 The example ALC packet format in the previous subsection doesn't use any Header Extensions. Examples of what they're used for:

  • Extended-size versions of header fields that already exist.
  • Sender and Receiver authentication information.

You can tell a Header Extension is there from the LCT header length (HDR_LEN). If HDR_LEN is bigger than the standard header, the leftover header space is filled with Header Extension fields 👀

If they're present, Header Extensions MUST be processed so that they get recognized before any congestion control procedure runs or a packet gets accepted 💅 The default for unrecognized Header Extensions is to ignore them. That's what lets backward-compatible upgrades land in ALC without changing the ALC version number 🌸 Non backward-compatible Header Extensions CANNOT be introduced without changing the ALC version number. No shortcuts, bestie 🙅

There are two formats for Header Extension fields, shown below. The first one is for variable-length extensions, with HET values between 0 and 127. The second one is for fixed-length extensions (one 32-bit word), using HET values from 127 to 255 🧚

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  HET (<=127)  |       HEL     |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    .                                                               .
    .              Header Extension Content (HEC)                   .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  HET (>=128)  |       Header Extension Content (HEC)          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 - Format of additional headers 🎀

Here's the breakdown of each sub-field 🔍

  • Header Extension Type (HET): 8 bits The type of the Header Extension. This document defines a bunch of possible types, and more can be defined in future versions of the spec. HET values from 0 to 127 are for variable-length Header Extensions. HET values from 128 to 255 are for fixed-length 32-bit Header Extensions.
  • Header Extension Length (HEL): 8 bits The length of the whole Header Extension field, counted in multiples of 32-bit words. This field MUST be present for variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and 255).
  • Header Extension Content (HEC): variable length The content of the Header Extension. Its format depends on the Header Extension type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length ones, the HEC field's size is set by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also, the total size of the LCT header, including all Header Extensions and all optional header fields, cannot go over 255 32-bit words 🙈

Header Extensions are split into general LCT extensions and Protocol Instantiation specific ones (PI-specific) 💜 General LCT extensions have HET in the ranges 0:63 and 128:191 (inclusive). PI-specific extensions have HET in the ranges 64:127 and 192:255 (inclusive).

General LCT extensions are meant to let backward-compatible enhancements land in LCT without changing the LCT version number. Non backward-compatible Header Extensions CANNOT be introduced without changing the LCT version number. Same energy as before, periodt 💅

PI-specific extensions are reserved for PI-specific use, with semantic and default parsing actions defined by the PI 🧁

The following general LCT Header Extension types are defined:

  • EXT_NOP=0: No-Operation extension. The information in this extension field MUST be ignored by receivers.
  • EXT_AUTH=1: Packet authentication extension. This carries information used to authenticate the sender of the packet. The format of this Header Extension and how it gets processed is outside the scope of this document. It's to be communicated out-of-band as part of the Session Description 🔐 It is RECOMMENDED that senders provide some form of packet authentication. If EXT_AUTH is present, whatever packet authentication checks can be done right when the packet arrives SHOULD be done before accepting the packet and doing any congestion control-related action on it. Some packet authentication schemes add a delay of several seconds between when a packet is received and when it's fully authenticated. Any congestion control related action that's appropriate MUST NOT be postponed by that full packet authentication.

All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content 🫶

For this version of ALC, the following PI-specific extension is defined:

  • EXT_FTI=64: FEC Object Transmission Information extension. Its purpose is to carry the FEC Object Transmission Information for an object in-band. The format of this Header Extension and how it gets processed is outside the scope of this document. It's to be communicated out-of-band as part of the Session Description 🧚

4.4. Sender Operation 🚀

The sender operation when using ALC includes all the points made about the sender operation when using the LCT building block [11], the FEC building block [10], and the multiple rate congestion control building block. So you get everything from those, no skipping 😌

A sender using ALC MUST make the required Session Description available, as described in Section 2.4. A sender also MUST make the required FEC Object Transmission Information available, as described in Section 2.3 📋

Within a session, a sender transmits a sequence of packets to the channels associated with the session. The ALC sender MUST obey the rules for filling in the CCI field in the packet headers, and MUST send packets at the right rates to the channels associated with the session, as dictated by the multiple rate congestion control building block 🏃‍♀️

The ALC sender MUST use the same TSI for all packets in the session. Several objects MAY be delivered within the same ALC session. If more than one object is going to be delivered within a session, then the sender MUST use the TOI field, each object MUST be identified by a unique TOI within the session, and the sender MUST use the corresponding TOI for all packets belonging to the same object. The FEC Payload ID MUST correspond to the encoding symbol(s) for the object carried in the packet's payload 🍓

Objects MAY be transmitted sequentially within a session, and they MAY be transmitted concurrently. However, it's good practice to only send objects concurrently in the same session if the receivers taking part in that portion of the session are interested in receiving all of the objects. Why? Because it wastes bandwidth and networking resources to have receivers pull down data for objects they don't care about 😭 There are no rules about mixing packets for different objects within the session, though. This affects the protocol's efficiency, but it doesn't affect the correctness or the inter-operability of ALC between senders and receivers ✨

Typically, the sender(s) keep sending packets in a session until the transmission is considered complete. The transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers 🌈

It is RECOMMENDED that packet authentication be used. If packet authentication is used, then the Header Extensions described in Section 4.3 MUST be used to carry the authentication 🔐

Packet sizes are not restricted by this document. Still, network efficiency considerations suggest the sender uses the largest packet payload size possible, but in a way that packets don't exceed the network's maximum transmission unit size (MTU). Otherwise fragmentation coupled with packet loss might cause severe inefficiency in the transmission 💀

It is RECOMMENDED that all packets have the same or very similar sizes, because this can have a severe impact on how well the multiple rate congestion control building block works 🦋

4.5. Receiver Operation ✨

okay bestie, the receiver side 🦋 is basically the mirror image of the sender side, and it includes EVERYTHING from the LCT building block [11], the FEC building block [10], and the multiple rate congestion control building block. no cap, it's giving continuity 💅

To be able to participate in a session, a receiver MUST obtain the REQUIRED Session Description as listed in Section 2.4. How receivers get a Session Description is outside the scope of this document 🎀

To be a receiver in a session, the receiver MUST be able to process the ALC header. The receiver MUST be able to discard, forward, store or process the other headers and the packet payload. If a receiver can't process the ALC header, it MUST drop from the session 💀

To be able to participate in a session, a receiver MUST implement the multiple rate congestion control building block using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the multiple rate congestion control building block, it MUST NOT join the session 🙈

Several objects can be carried either sequentially or concurrently within the same session 🌈 In this case, each object is identified by a unique TOI. Note that even if a sender stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different channels. So receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time ⏳

As described in Section 2.3, a receiver MUST obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets 🧚

A receiver MAY concurrently join multiple ALC sessions from one or more senders. The receiver MUST perform congestion control on each such session. The receiver MAY make choices to optimize the packet flow performance across multiple sessions, as long as the receiver still adheres to the multiple rate congestion control building block for each session individually ✨ multitasking queen behavior 👑

Upon receipt of each packet, the receiver proceeds with the following steps in the order listed 📋

  • (1) The receiver MUST parse the packet header and verify that it is a valid header. If it is not valid, then the packet MUST be discarded without further processing. If multiple packets are received that cannot be parsed, then the receiver SHOULD leave the session.
  • (2) The receiver MUST verify that the sender IP address together with the TSI carried in the header matches one of the (sender IP address, TSI) pairs that was received in a Session Description and that the receiver is currently joined to. If there is not a match, then the packet MUST be discarded without further processing. If multiple packets are received with non-matching (sender IP address, TSI) values, then the receiver SHOULD leave the session. If the receiver is joined to multiple ALC sessions, then the remainder of the steps are performed within the scope of the (sender IP address, TSI) session of the received packet 🔍
  • (3) The receiver MUST process and act on the CCI field in accordance with the multiple rate congestion control building block 🚦
  • (4) If more than one object is carried in the session, the receiver MUST verify that the TOI carried in the LCT header is valid. If the TOI is not valid, the packet MUST be discarded without further processing 🗂️
  • (5) The receiver SHOULD process the remainder of the packet, including interpreting the other header fields appropriately, and using the FEC Payload ID and the encoding symbol(s) in the payload to reconstruct the corresponding object 🧩

It is RECOMMENDED that packet authentication be used. If packet authentication is used, then it is RECOMMENDED that the receiver immediately check the authenticity of a packet before proceeding with step (3) above. If immediate checking is possible and if the packet fails the check, then the receiver MUST discard the packet and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control 🔐

Some packet authentication schemes, such as TESLA [14], do not allow an immediate authenticity check. In this case, the receiver SHOULD check the authenticity of a packet as soon as possible, and if the packet fails the check, then it MUST be discarded before step (5) above and the receiver MUST reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control 🕰️

5. Security Considerations 🛡️

The same security considerations that apply to the LCT, FEC and the multiple rate congestion control building blocks also apply to ALC.

Because of the use of FEC, ALC is especially vulnerable to denial-of-service attacks by attackers that try to send forged packets to the session, which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the object by receivers. ALC is also particularly affected by such an attack because many receivers may receive the same forged packet. 😭 There are two ways to protect against such attacks, one at the application level and one at the packet level. It is RECOMMENDED that prevention be provided at both levels.

At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed, to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity protection, a digital signature verifiable by the receiver SHOULD be used to provide this application level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail, and in this case the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial of service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application level integrity check of the received object is outside the scope of this document.

At the packet level, it is RECOMMENDED that a packet level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing FEC data for the object arriving from the specified sender. Packet level authentication has the advantage that corrupt or forged packets can be discarded individually, and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial of service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work 🔏

In addition to providing protection against reconstruction of inaccurate objects, packet level authentication can also provide some protection against denial of service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet level authentication be used to protect against such attacks. TESLA [14] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate 🥶

Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers, to limit the possibility of a bad agent injecting forged packets into the multicast tree data path 🚧

A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.

Another vulnerability of ALC is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document 🕵️‍♀️

6. IANA Considerations 📚

No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by ALC does require IANA registration of the FEC codecs used 🗒️

7. Intellectual Property Issues ⚖️

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.

8. Acknowledgments 🫶

Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their detailed comments on this document 💜

9. References 📚

Okay bestie, here's the reading list. Every single source the RFC leans on is listed below, with all the details kept exactly as they were. 🌸

  • [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
  • [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
  • [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  • [6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
  • [7] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
  • [8] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
  • [9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
  • [10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
  • [11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451 December 2002.
  • [12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
  • [13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [14] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
  • [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [16] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.

Authors' Addresses 💌

Here are the people who wrote this thing, with their addresses and emails exactly as they appear. Iconic behaviour from the whole squad. 👑

Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA, USA, 94538

EMail: luby@digitalfountain.com


Jim Gemmell
Microsoft Research
455 Market St. #1690
San Francisco, CA, 94105

EMail: jgemmell@microsoft.com


Lorenzo Vicisano
cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA, USA, 95134

EMail: lorenzo@cisco.com


Luigi Rizzo
Dip. Ing. dell'Informazione,
Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy

EMail: luigi@iet.unipi.it


Jon Crowcroft
Marconi Professor of Communications Systems
University of Cambridge
Computer Laboratory
William Gates Building
J J Thomson Avenue
Cambridge CB3 0FD, UK

EMail: Jon.Crowcroft@cl.cam.ac.uk

Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈

Here's the legal bit, and it matters, so read it carefully. This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The one condition is 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. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English.

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💜

This document and the information in it are 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. Thank you to them for keeping the lights on, bestie. ✨

📦 where this page comes from