RFC 4586
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations
RFC 4586 🎀 Part 1 of 6
Okay bestie, let's get into RFC 4586 ✨ Its full title is Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations. It was written by C. Burmeister, R. Hakenberg, A. Miyazaki (Panasonic), J. Ott (Helsinki University of Technology), N. Sato, and S. Fukunaga (Oki) 💜 It came out in July 2006, it's Informational, and its header doesn't list anything it obsoletes or updates.
Status of This Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 🦋
Abstract 💖
Okay so this doc shows what happened when people simulated the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, which everyone calls AVPF 🎀 They tested unicast and multicast setups and a bunch of different protocol and environment configs. The verdict? The timing rules give better feedback delay, AND they still keep the well-accepted RTP rules for how much bit rate control traffic is allowed to use. Slay 💅✨
Table of Contents 🗺️
1. Introduction ....................................................3
2. Timing Rules of the Extended RTP Profile for RTCP-Based
Feedback ........................................................4
3. Simulation Environment ..........................................5
3.1. Network Simulator Version 2 ................................5
3.2. RTP Agent ..................................................5
3.3. Scenarios ..................................................5
3.4. Topologies .................................................6
4. RTCP Bit Rate Measurements ......................................6
4.1. Unicast ....................................................7
4.2. Multicast .................................................10
4.3. Summary of the RTCP Bit Rate Measurements .................10
5. Feedback Measurements ..........................................11
5.1. Unicast ...................................................11
5.2. Multicast .................................................12
5.2.1. Shared Losses vs. Distributed Losses ...............13
6. Investigations on "l" ..........................................14
6.1. Feedback Suppression Performance ..........................16
6.2. Loss Report Delay .........................................18
6.3. Summary of "l" Investigations .............................18
7. Applications Using AVPF ........................................19
7.1. NEWPRED Implementation in NS2 .............................19
7.2. Simulation ................................................21
7.2.1. Simulation A - Constant Packet Loss Rate ...........21
7.2.2. Simulation B - Packet Loss Due to Congestion .......23
7.3. Summary of Application Simulations ........................24
8. Summary ........................................................24
9. Security Considerations ........................................25
10. Normative References ..........................................26
11. Informative References ........................................261. Introduction 🌈
Okay so the Real-time Transport Protocol (RTP) is EVERYWHERE for sending real-time or near real-time media over the Internet 📡 It was originally built to work great for multicast groups at super large scale, but its scope isn't limited to that. More and more apps use RTP for small multicast groups (like video conferences) or even unicast (like IP telephony and media streaming) 🎧
RTP comes with its bestie protocol, the Real-time Transport Control Protocol (RTCP) 🫶 RTCP keeps an eye on how the media is being transmitted and sends back feedback about reception quality. It can also do loose session control. Since the original design had huge multicast groups in mind, the rules about when to send feedback were kept really tight so you don't get feedback explosions or feedback-related congestion in the network 🙈 And honestly? RTP and RTCP have proven they work well on the Internet, especially in large multicast groups, which is why they're so widely used today 👑
BUT (and this is the tea) apps that only send media to small multicast groups or to unicast might actually benefit from more frequent feedback 🍓 The source of the packets may be able to react to changes in reception quality, which could come from varying network utilization (like congestion) or other stuff. Possible reactions include transmission rate adaptation using a congestion control algorithm, or turning on error resilience features for the media stream, like retransmissions, reference picture selection, NEWPRED, etc. 🔥
So yeah, more frequent feedback could be really desirable for reception quality, but RTP restricts the use of RTCP feedback. 😭 The solution was to create a brand new extended RTP profile that redefines some of the RTCP timing rules, while keeping most of the RTP and RTCP algorithms that have already proven themselves 💅 The new rules are meant to scale from unicast up to multicast, with unicast and small multicast apps getting the biggest gain. You can find a detailed description of the new profile and its timing rules in [1] 📖
This document investigates the new algorithms with simulations ✨ We show that the new timing rules scale well and behave in a network-friendly way. First, Section 2 roughly describes the key features of the new RTP profile that matter for our simulations. After that, Section 3 describes the environment we used to run the simulations. Section 4 shows simulation results that demonstrate backwards compatibility with RTP and that the new profile is network-friendly in terms of the bandwidth used for RTCP traffic. In Section 5, we show the benefit apps could get from implementing the new profile. In Section 6, we looked at the effect of the parameter "l" (used to calculate the T_dither_max value) on algorithm performance. Finally, in Section 7, we show the performance gain we could get for a special application, namely NEWPRED in [6] and [7] 🦋
2. Timing Rules of the Extended RTP Profile for RTCP-Based Feedback 🧚
As I said above, RTP restricts how RTCP feedback is used. The main RTCP restrictions are these:
- RTCP messages are sent in compound packets, i.e., every RTCP packet contains at least one sender report (SR) or receiver report (RR) message and a source description (SDES) message.
- The RTCP compound packets are sent in time intervals (
T_rr), which are computed as a function of the average packet size, the number of senders and receivers in the group, and the session bandwidth (5% of the session bandwidth is used for RTCP messages; this bandwidth is shared between all session members, where the senders may get a larger share than the receivers.) - The average minimum interval between two RTCP packets from the same source is 5 seconds.
Honestly these rules are SO good at preventing feedback explosion and scaling to large multicast groups 🙌 But they don't allow timely feedback at all 🥲 The second rule does scale down to small groups or unicast (where the interval might be as small as a few milliseconds), but the third rule can stop receivers from sending feedback in a timely way.
The timing rules for sending RTCP feedback in the new RTP profile [1] have two key parts. First, the minimum interval of 5 seconds gets abolished 💥 Second, during every other one of their (now pretty small) RTCP intervals, receivers get one chance to send an RTCP packet "early". That means it isn't sent according to the calculated interval, but basically right away ⚡ It's important to note that the RTCP interval calculation is still inherited from the original RTP specification 🎀
The full spec and all the details of the extended timing rules are in [1]. Instead of re-describing the algorithms here, we just reference the original specification [1], so we use the same variable names and abbreviations as in [1] too 🫶
3. Simulation Environment 🌸
This section describes the simulation testbed we used for the investigations and its key features 💻 The extensions we needed for the simulator are roughly described in the subsections below.
3.1. Network Simulator Version 2 🖥️
The simulations were run with the network simulator version 2 (ns2) 🌈 ns2 is an open source project written in a combo of Tool Command Language (TCL) and C++. The scenarios are set up in TCL. The scripts let you specify the topologies (nodes and links, bandwidths, queue sizes, or error rates for links) and the parameters of the "agents", i.e., protocol configurations 🍓 The protocols themselves are implemented in C++ in the agents, which are connected to the nodes. The documentation for ns2 and the newest version can be found in [4] 📚
3.2. RTP Agent 🧁
We built a brand new agent based on RTP/RTCP 💖 RTP packets are sent at a constant packet rate with the correct header sizes. RTCP packets are sent according to the timing rules of [2] and [3], and its algorithms for group membership maintenance are implemented too. Sender and receiver reports are sent as well 📨
We also extended the agent to support the extended profile [1] 🦋 You can turn the new timing rules on and off with parameter settings in TCL 🎀
3.3. Scenarios 🗺️
The scenarios we simulated are defined in TCL scripts 💜 We set up several different topologies, ranging from unicast with two session members up to multicast with up to 25 session members 👑 Depending on the sending rates and the corresponding link bandwidths, congestion losses may occur. In some scenarios, bit errors are inserted on certain links 🙈 We simulated groups with RTP/AVP agents, RTP/AVPF agents, and mixed groups 🫶
The feedback messages are generally NACK messages, as defined in [1], and they're triggered by packet loss 🔥
3.4. Topologies ✨
okay so, we mainly simulated four different topologies to show off the key features of the extended profile 💅 for some specific simulations we used different topologies too, and when that happens the results description tells you 🧚 the main four are named after how many participating RTP agents they have: T-2, T-4, T-8, and T-16. T-2 is the unicast one, T-4 has four agents, and so on 🌸 here's Figure 1 🦋
A5
A5 | A6
/ | /
/ | /--A7
/ |/
A2 A2-----A6 A2--A8
/ / / A9
/ / / /
/ / / /---A10
A1-----A2 A1-----A3 A1-----A3-----A7 A1------A3<
\ \ \ \---A11
\ \ \ \
\ \ \ A12
A4 A4-----A8 A4--A13
|\
| \--A14
| \
| A15
A16
T-2 T-4 T-8 T-16Figure 1: Simulated topologies
4. RTCP Bit Rate Measurements 🔥
the new timing rules allow more frequent RTCP feedback for small multicast groups 💖 in large groups the algorithm acts pretty much like the normal RTCP timing rules 🫶 more frequent feedback is great and all, but it's a hard no to let the RTCP bit rate climb above a fixed limit, which is 5% of the total RTP bandwidth according to RTP 🚫 this section shows that the new timing rules keep RTCP bandwidth usage under that 5% limit for all the investigated scenarios, topologies, and group sizes ✨ we also show that mixed groups (some members using AVP, some AVPF) can be allowed, and that each session member behaves fairly according to its own specification 👑 other values for the RTCP bandwidth limit may be specified using the RTCP bandwidth modifiers as in [10].
4.1. Unicast
first we measured the RTCP bandwidth share in the unicast topology T-2 🦋 even with a fixed topology and group size, there are several protocol parameters that get varied so we can simulate a huge range of scenarios 🍓 we varied the configurations of the agents, so they may use AVP or AVPF. that means it's possible for one agent to use AVP and the other AVPF in one RTP session, which is how we test the backwards compatibility of the AVPF profile 🙈
next up, scenarios where no losses occur 💅 in this case both RTP session members send RTCP compound packets at regular intervals. they're calculated as T_rr if they use AVPF, and they use a minimum interval of 5 seconds (on average) if they implement AVP. no early packets get sent, because there's no need for early feedback 💀 still, it's important to see that not more than 5% of the session bandwidth is used for RTCP, and that AVP and AVPF members can coexist without interference ✨ the results are in Table 1 🎀
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.01 | 0.02 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 |
|200 kbps | 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.77 | 0.79 | 1.58 |
Table 1: Unicast simulations without packet losslook at this 🤩 in configurations where both agents use the new timing rules, each of them uses, at most, about 2.5% of the session bandwidth for RTP, which adds up to 5% of the session bandwidth for both 💖 this holds whether the agent is a sender or a receiver. when agent A1 uses AVP and agent A2 uses AVPF, the total RTCP session bandwidth drops 📉 that's because agent A1 can only send RTCP packets with an average minimum interval of 5 seconds, so only a small fraction of the session bandwidth goes to its RTCP packets. for a high-bit-rate session (session bandwidth = 2 Mbps), the fraction of RTCP packets from agent A1 is as small as 0.01% 🙈 for smaller session bandwidths the fraction goes up, because the same amount of RTCP data gets sent. the bandwidth share used by RTCP packets from agent A2 is no different from what it was when both agents implemented AVPF. so the interaction of AVP and AVPF agents is not problematic in these scenarios at all 🫶
in our second unicast experiment, we show that the allowed RTCP bandwidth share is not exceeded, even when packet loss happens 😭 we simulated a constant byte error rate (BYER) on the link. the byte errors get inserted randomly, following a uniform distribution.
packets with byte errors are discarded on the link, so the receiving agents won't see the loss right away. the agents detect packet loss by spotting a gap in the sequence number 🕵️
when an AVPF agent detects a packet loss, the early feedback procedure starts 🔥 as described in AVPF [1], in unicast T_dither_max is always zero, so an early packet can be sent immediately if allow_early is true. if the last packet was already an early one (i.e., allow_early = false), the feedback might get appended to the next regularly scheduled receiver report. the max_feedback_delay parameter (which we set to 1 second in our simulations) decides whether that's allowed 👑
the results are in Table 2, and as you can see there's no difference in the RTCP bandwidth share, whether or not losses occur 🌈 this is what we expected, because even though the RTCP packet size grows and early packets get sent, the interval between packets increases too, so the RTCP bandwidth stays the same. only the RTCP bandwidth of the agents using AVP goes up a bit. this is because the interval between packets is still 5 seconds (on average), but the packet size grew because of the appended feedback 🍓
| | | | | | Used RTCP Bit Rate |
| Session | Send | Rec. | AVP | AVPF | (% of session bw) |
|Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum |
+---------+------+------+------+------+------+------+------+
| 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
| 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 |
| 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 |
| 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 |
| 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.02 | 0.03 |
| 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 |
|200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 |
|200 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 |
|200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 |
|200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 |
|200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 |
|200 kbps | 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 |
| 20 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 |
| 20 kbps | 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 |
| 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 |
| 20 kbps | 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 |
| 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 |
| 20 kbps | 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 |
Table 2: Unicast simulations with packet loss4.2. Multicast
next, we looked at the RTCP bandwidth share in multicast scenarios 🌸 we simulated topologies T-4, T-8, and T-16 and measured the fraction of session bandwidth used for RTCP packets. we tried lots of different situations and protocol configurations (e.g., with or without bit errors, groups with AVP and/or AVPF agents, etc.). for readability, we only show selected results. for documentation of all the results, see [5] 📚
the simulations of the different topologies, in scenarios where no losses occur (neither from bit errors nor from congestion), show behaviour similar to the unicast case ✨ for all group sizes, the maximum RTCP bit rate share used is 5.06% of the session bandwidth, in a simulation of 16 session members in a low-bit-rate scenario (session bandwidth = 20 kbps) with several senders 😳 in all other scenarios without losses, the RTCP bit rate share used is below that. so the requirement that not more than 5% of the session bit rate should be used for RTCP is fulfilled with reasonable accuracy 💜
simulations where bit errors are randomly inserted in RTP and RTCP packets, and the corrupted packets get discarded, give the same results 🎀 the 5% rule holds (at most 5.07% of the session bandwidth is used for RTCP).
finally, we ran simulations where we reduced the link bandwidth to cause congestion-related losses 🔥 these are different from the bit error simulations, because the losses happen more in bursts and are more correlated, including between different agents 🫠 the correlation and "burstiness" of the packet loss comes from the queuing discipline in the routers we simulated. we used simple FIFO queues with a drop-tail strategy to handle congestion. Random Early Detection (RED) queues may enhance performance, because the burstiness of the packet loss might be reduced, but that isn't the subject of our investigations and is left for future study 🧚 the delay between agents, which also affects RTP and RTCP packets, is much more variable because of the added queuing delay. still, the RTCP bit rate share used does not go beyond 5.09% of the session bandwidth 🥹 so for these special cases the requirement is fulfilled too, bestie 👑
4.3. Summary of the RTCP Bit Rate Measurements ✨
okay so bestie, the big takeaway here is that feedback implosion just doesn't happen 😭 for unicast and reasonable multicast scenarios 🙌 We're talking no feedback avalanche at all. And the RTCP bandwidth rule? It's giving compliant 💅 The requirement that at maximum 5% of the session bandwidth goes to RTCP is met in every single scenario we tested 🎀
5. Feedback Measurements 🔥
okay this section is where we check out the actual feedback delay results from our simulations 🦋 We used two metrics to judge how the algorithms performed: the "mean waiting time" (MWT) 🕐 and the count of feedback packets that were sent, suppressed, or not allowed 📊 The waiting time is measured at a given agent, from the moment it spots a packet loss event until the matching feedback goes out ⏱️ We figure the feedback's value drops the longer it takes to arrive, so MWT is a solid way to measure how much we gain by switching from AVP to AVPF 💜
here's the deal with the feedback an RTP/AVPF agent wants to send: it either gets sent or it doesn't 🤔 If it doesn't, that's either because of feedback suppression (someone else already sent the same feedback 🫶) or because the feedback wasn't allowed (the max_feedback_delay got exceeded 😬) We tracked every detected loss and logged whether the agent sent its feedback, and if not, why. The more feedback that wasn't allowed, the worse the algorithm is doing 💀 Combined with the waiting times, that gives us a really good read on how the whole scheme is performing ✨
5.1. Unicast 🎀
in the unicast case, the maximum dithering interval T_dither_max is fixed and set to zero 🙈 That makes sense because a unicast receiver has no reason to wait around for other receivers with the same feedback to send 🙅♀️ Feedback can still get delayed, though, or might not be permitted to go out at all 😭 The regularly scheduled packets are spaced according to T_rr, which in the unicast case depends mainly on the session bandwidth 🌸
Table 3 shows the mean waiting times (MWTs), measured in seconds, for some configurations of the unicast topology T-2 📈 It also lists how many feedback packets were sent or discarded (feedback sent (sent) or feedback discarded (disc)) 🍓 We skipped suppressed packets because feedback suppression doesn't apply to unicast, so that column isn't a thing here 🙃 In the simulations, agent A1 was the sender and agent A2 was a pure receiver 🧚
| | | Feedback Statistics |
| Session | | AVP | AVPF |
|Bandwidth| PLR | sent |disc| MWT | sent |disc| MWT |
+---------+-------+------+----+-------+------+----+-------+
| 2 Mbps | 0.001 | 781 | 0 | 2.604 | 756 | 0 | 0.015 |
| 2 Mbps | 0.01 | 7480 | 0 | 2.591 | 7548 | 2 | 0.006 |
| 2 Mbps | cong. | 25 | 0 | 2.557 | 1741 | 0 | 0.001 |
| 20 kbps | 0.001 | 79 | 0 | 2.472 | 74 | 2 | 0.034 |
| 20 kbps | 0.01 | 780 | 0 | 2.605 | 709 | 64 | 0.163 |
| 20 kbps | cong. | 780 | 0 | 2.590 | 687 | 70 | 0.162 |
Table 3: Feedback statistics for the unicast simulationslook at those numbers, bestie 😍 The mean waiting time drops dramatically when you use AVPF instead of AVP 🚀 AVP agents are stuck at around 2.5 seconds the whole time (half the minimum interval average) 😩 With AVPF, most configurations get it down to a few ms 🔥
in the high session bandwidth configurations, basically all triggered feedback gets sent 👑 That's because there's more RTCP bandwidth to go around ✨ There are only a few exceptions, and they're probably caused by more than one packet loss inside a single RTCP interval, where the first loss got sent super early by chance 🙈 The second feedback might get triggered after that early packet already went out, but too soon to tack it onto the next regularly scheduled report, thanks to the limit of the max_feedback_delay 😬
it's different when the session bandwidth is small, because the RTCP bandwidth share is pretty low and T_rr ends up larger 🐢 After an early packet goes out, the time until the next regularly scheduled packet can get really long 🥲 In some cases that time was bigger than the max_feedback_delay, and in those cases the feedback isn't allowed to be sent at all 💔
with a different max_feedback_delay setting, you can end up with either more feedback that isn't allowed plus a lower mean waiting time, or more feedback that does get sent but with a higher waiting time 🎭 So the parameter should be set with care, according to what the application actually needs 💅
5.2. Multicast 🌈
in this section we look at some feedback statistics from the multicast simulations ✨ We picked out a few characteristic and representative results 💜 We considered the topology T-16, and different scenarios and applications were simulated for it 🧚 The link parameters were set up like this: agents A2, A3, and A4 connect to the middle node of the multicast tree (that's agent A1) through high bandwidth, low-delay links 🚄 The other agents connect to nodes 2, 3, and 4 with different link characteristics 🎀
the agents on node 2 represent mobile users 📱 In certain configurations they deal with a certain byte error rate on their access links, and their delays are high 🥲 The agents on node 3 have low-bandwidth access links but don't suffer from bit errors 🐌 The last group, on node 4, has high bandwidth and low delay 🏎️
5.2.1. Shared Losses vs. Distributed Losses 🦋
in our first investigation, we wanted to see how the loss characteristic affects the algorithm's performance 🔍 We looked at cases where packet loss hits several users at the same time (shared losses) versus cases where it happens totally independently (distributed losses) 💫 Agent A1 is the sender here 📣 For shared losses, we put a constant byte error rate on one of the middle links, the one between A1 and A2 🔗 For distributed losses, we put the same byte error rate on all the links downstream of A2 🌊
these scenarios are super interesting because of the feedback suppression algorithm 👀 When every receiver shares the same loss, only one of them needs to send the loss report 🙌 So if a member gets feedback with the same content it had scheduled, it suppresses its own scheduled feedback 🤫 That suppressed feedback doesn't count toward the mean waiting times, which is lowkey genius 🧠 We expected shorter waiting times for shared losses, since there's a high chance one receiver can send the feedback more or less right away ⚡ The results are below 👇
| | Feedback Statistics |
| | Shared Losses | Distributed Losses |
|Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT |
+-----+----+----+----+----+-----+----+----+----+----+-----+
| A2 | 274| 351| 25| 650|0.267| -| -| -| -| -|
| A5 | 231| 408| 11| 650|0.243| 619| 2| 32| 653|0.663|
| A6 | 234| 407| 9| 650|0.235| 587| 2| 32| 621|0.701|
| A7 | 223| 414| 13| 650|0.253| 594| 6| 41| 641|0.658|
| A8 | 188| 443| 19| 650|0.235| 596| 1| 32| 629|0.677|
Table 4: Feedback statistics for multicast simulationsTable 4 shows the feedback statistics for a simulation with a large group size 🐘 All 16 agents of topology T-16 joined the RTP session 🎉 But only agent A1 acts as an RTP sender; everyone else is a pure receiver 🎤 Only 4 or 5 agents suffer from packet loss: A2, A5, A6, A7, and A8 for shared losses, and A5, A6, A7, and A8 for distributed losses 🥺 The number of session members is the same in both cases, so T_rr is also the same on average ⚖️ Even so, the mean waiting times drop by more than 50% for shared losses 📉 That proves our assumption that shared losses boost the algorithm's performance, no matter the loss characteristic 🙌✨
the feedback suppression mechanism seems to be working really well 💅 Some feedback still comes from different receivers, i.e., 1150 loss reports were sent in total for only 650 lost packets, so loss reports got received on average 1.8 times 📬 But most of the redundant feedback got suppressed 🫶 Specifically, 2023 loss reports were suppressed out of 3250 individual detected losses, which means more than 60% of the feedback was actually suppressed 🎀🔥
6. Investigations on "l" 🔥
okay so this section is where we poke at the "l" parameter and see how it messes with T_dither_max in RTP/AVPF agents 🧚 we're looking at feedback suppression performance AND report delay across three sample scenarios, bestie 💅
Here's the vibe: for all receivers, the formula is T_dither_max = l * T_rr, and we're using l = 0.5 🎀 why? Because if a receiver has no round-trip time (RTT) estimation, it literally doesn't know how long to wait for everyone else to send feedback 😭 If the wait is too short, the feedback suppression algorithm fails, but if it's too long, the wait gets unnecessarily stretched and the feedback becomes less valuable. The perfect number could be found for each case, but that's not always doable, and tbh that's fine 🫶 A decreased feedback value or a failed suppression mechanism doesn't wreck network stability. We showed for the distributed-losses cases that the overall bandwidth constraints are kept no matter what, so picking the wrong time value only costs some performance. ✨
Now, a good measure for T_dither_max is the RTCP interval T_rr 🌸 it grows with the number of session members, and we know we can send feedback at least every T_rr. So making T_dither max bigger than T_rr would be giving no sense at all 💀 By choosing T_rr/2, we make sure that sometimes (like when a loss gets detected in the first half of the interval between two regularly scheduled RTCP packets) we're allowed to send early packets. And because T_dither is random, we still have a really good shot at sending that early packet on time 🦋
The AVPF profile says the T_dither_max calculation, as given above, is the same for session members with an RTT estimation AND those without one 👑 If it weren't, people using different formulas could end up with super different mean waiting times before sending feedback, which means different reporting priorities. Like, in a scenario where T_rr = 1 s and the RTT = 100 ms, receivers using the RTT estimation would, on average, send more feedback than those who aren't 😬 That could cancel out the feedback suppression mechanism and even cause feedback implosion, which is NOT the vibe.
Also, in a general case where losses are shared, the feedback suppression mechanism only works if each receiver's feedback packets have enough time to reach all the other receivers before the calculated T_dither_max seconds are up ⏰ So in scenarios of very high bandwidth (small T_rr), the calculated T_dither_max could end up way smaller than the propagation delay between receivers. That means the suppression mechanism fails 🙈 One fix could be limiting the bandwidth available to receivers (see [10]) so this doesn't happen. Another could be developing a feedback suppression mechanism based on the RTT estimation between senders. We're not going to dig into that here, and it might be the subject of another document 📚 Just note that a really high bandwidth media stream isn't that likely to rely on this kind of error repair in the first place 💖
Okay, so next up, we define three representative sample scenarios 🧚 We're using the topology from the previous section, T-16. Most of the agents barely contribute to the simulations, because we only introduced an error rate on the link between the sender A1 and the agent A2 🌈
The first scenario is about losses being shared between two agents, where one agent sits upstream on the path between the other agent and the sender. So agent A2 and agent A5 see the same losses, the ones introduced on the link between the sender and agent A2. Agents A6, A7, and A8 do NOT join the RTP session. From the other agents, only A3 and A9 join. Everyone is a pure receiver, except A1, which is the sender. 🍓
The second scenario ALSO has losses shared between two agents, but this time the agents are on different branches of the multicast tree 🌿 The delays to the sender are roughly the same magnitude. Agents A5 and A6 share the same losses. Agents A3 and A9 join the RTP session, but they're pure receivers and don't see any losses 🦋
Finally, the third scenario has losses shared between A5 and A6 again, with the same agents active as in the second scenario 💜 The difference is the link delays. The delay between agents A2 and A5 is reduced to 20 ms, and between A2 and A6 it's 40 ms ⭐
All agents besides agent A1 are pure RTP receivers 🫶 So they don't have an RTT estimation to the source. T_dither_max is calculated with the formula above, depending only on T_rr and l, which means all agents should calculate roughly the same T_dither_max ✨
6.1. Feedback Suppression Performance
Quick definition: the feedback suppression rate for an agent is the ratio of feedback packets NOT sent out of the total feedback packets that agent intended to send (aka the sum of sent and not sent) 🧮 Reasons for not sending a packet include the receiver already seeing the same loss reported in a receiver report from another session member, OR the max_feedback_delay (application-specific) getting surpassed 🙅♀️
Here's the tea on agent Af, the one further from the sender 🍵 Table 5 shows that the feedback suppression rate goes up as l goes up. There IS a threshold, though (it depends on the environment) past which the extra gain isn't significant anymore 🥱
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.671 | 0.051 | 0.089 |
| 0.25 | 0.582 | 0.060 | 0.210 |
| 0.50 | 0.524 | 0.114 | 0.361 |
| 0.75 | 0.523 | 0.180 | 0.370 |
| 1.00 | 0.523 | 0.204 | 0.369 |
| 1.25 | 0.506 | 0.187 | 0.372 |
| 1.50 | 0.536 | 0.213 | 0.414 |
| 1.75 | 0.526 | 0.215 | 0.424 |
| 2.00 | 0.535 | 0.216 | 0.400 |
| 3.00 | 0.522 | 0.220 | 0.405 |
| 4.00 | 0.522 | 0.220 | 0.405 |Table 5: Fraction of feedback that was suppressed at agent (Af) of the total number of feedback messages the agent wanted to send
Table 6 is giving similar energy for agent An, the one nearer to the sender 💅
| | Feedback Suppression Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.056 | 0.056 | 0.090 |
| 0.25 | 0.063 | 0.055 | 0.166 |
| 0.50 | 0.116 | 0.099 | 0.255 |
| 0.75 | 0.141 | 0.141 | 0.312 |
| 1.00 | 0.179 | 0.175 | 0.352 |
| 1.25 | 0.206 | 0.176 | 0.361 |
| 1.50 | 0.193 | 0.193 | 0.337 |
| 1.75 | 0.197 | 0.204 | 0.341 |
| 2.00 | 0.207 | 0.207 | 0.368 |
| 3.00 | 0.196 | 0.203 | 0.359 |
| 4.00 | 0.196 | 0.203 | 0.359 |Table 6: Fraction of feedback that was suppressed at agent (An) of the total number of feedback messages the agent wanted to send
Now the feedback suppression FAILURE rate, shown in Table 7 📉 The extra performance increase stops being significant past a certain threshold, and the scenario definitely matters here too 🎭
| |Feedback Suppr. Failure Rate |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.273 | 0.893 | 0.822 |
| 0.25 | 0.355 | 0.885 | 0.624 |
| 0.50 | 0.364 | 0.787 | 0.385 |
| 0.75 | 0.334 | 0.679 | 0.318 |
| 1.00 | 0.298 | 0.621 | 0.279 |
| 1.25 | 0.289 | 0.637 | 0.267 |
| 1.50 | 0.274 | 0.595 | 0.249 |
| 1.75 | 0.274 | 0.580 | 0.235 |
| 2.00 | 0.258 | 0.577 | 0.233 |
| 3.00 | 0.282 | 0.577 | 0.236 |
| 4.00 | 0.282 | 0.577 | 0.236 |Table 7: The ratio of feedback suppression failures.
Summing up the feedback suppression results 🧁 generally, performance goes up as l goes up. BUT past a certain threshold, which depends on environment parameters like propagation delays or session bandwidth, the extra increase isn't significant anymore. That threshold is NOT uniform across all scenarios 🙃 A value of l=0.5 seems to give reasonable results with acceptable (though not optimal) overhead ✨
6.2. Loss Report Delay
In this section, we show the measured report delay from the simulations of the three sample scenarios ⏱️ This is a metric of how the algorithms are performing, because the value of the feedback for the sender usually drops the longer it takes to arrive 😤 The loss report delay is measured at the sender as the time between sending a packet and receiving the first matching loss report 📬
| | Mean Loss Report Delay |
| l | Scen. 1 | Scen. 2 | Scen. 3 |
+------+---------+---------+---------+
| 0.10 | 0.124 | 0.282 | 0.210 |
| 0.25 | 0.168 | 0.266 | 0.234 |
| 0.50 | 0.243 | 0.264 | 0.284 |
| 0.75 | 0.285 | 0.286 | 0.325 |
| 1.00 | 0.329 | 0.305 | 0.350 |
| 1.25 | 0.351 | 0.329 | 0.370 |
| 1.50 | 0.361 | 0.363 | 0.388 |
| 1.75 | 0.360 | 0.387 | 0.392 |
| 2.00 | 0.367 | 0.412 | 0.400 |
| 3.00 | 0.368 | 0.507 | 0.398 |
| 4.00 | 0.368 | 0.568 | 0.398 |Table 8: The mean loss report delay, measured at the sender.
As Table 8 shows, the delay goes up, in general, as l goes up 📈 A similar effect to feedback suppression performance is happening too: past a certain threshold, the extra increase in delay stops being significant. That threshold depends on the environment and seems to be linked to the threshold where the feedback suppression gain stops increasing anymore 🫧
6.3. Summary of "l" Investigations ✨
okay so bestie, we showed experimentally that the feedback suppression performance gets better as l goes up 📈, and the report delay goes up right along with it 😭. this leads to a threshold where neither the performance nor the delay climbs any further 🧚. and the threshold depends on the environment 🌸
so finding an optimum value of l is literally not possible 💀, because it's always a trade-off between delay and feedback suppression performance 🎀. with l=0.5, we think we landed on a trade-off that's acceptable for typical applications and environments 💅✨
7. Applications Using AVPF 🦋
ngl this section is so cute 🥹 NEWPRED is one of the error resilience tools, defined in both ISO/IEC MPEG-4 visual part and ITU-T H.263 🎬. NEWPRED gets fast error recovery by using feedback messages 💖. we simulated how NEWPRED behaves in the network simulator environment described above and measured the waiting time statistics 📊, to check that the extended RTP profile for RTCP-based feedback (AVPF) [1] is appropriate for the NEWPRED feedback messages 🫶. the simulation results, which show up in the following sections, show that the waiting time is small enough to get the expected performance of NEWPRED 🔥
7.1. NEWPRED Implementation in NS2 🌈
the agent that does the NEWPRED functionality is called the NEWPRED agent, and it's different from the RTP agent we described above 🧚 a few of the added features are in these points:
Application Feedback The "Application Layer Feedback Messages" format is used to transmit the NEWPRED feedback messages 💜. so the NEWPRED functionality gets added to the RTP agent ✨. the NEWPRED agent creates one NACK message for each lost segment of a video frame, then assembles multiple NACK messages for the segments in the same video frame into one Application Layer Feedback Message 🎀. there are two modes in NEWPRED, NACK mode and ACK mode [6][7], but only NACK mode is used in these simulations 🙈. in this simulation the RTP layer doesn't generate feedback messages. instead, the decoder (NEWPRED) generates a NACK message when the segment can't be decoded because the data hasn't arrived or a loss of reference picture has happened 😭. the decoder detects those conditions using the frame number, segment number, and whether reference pictures exist in the decoder 💅
the parameters of the NEWPRED agent are:
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)Generation of NEWPRED's NACK Messages The NEWPRED agent generates NACK messages when segments are lost 🥺
a. the NEWPRED agent generates multiple NACK messages per video frame when multiple segments are lost 🍓. these get assembled into one Feedback Control Information (FCI) message per video frame ✨. if there's no lost segment, no message is generated or sent 🙅♀️
b. one NACK message is 4 bytes long 💖. let num be the number of NACK messages in one video frame (1 <= num <= seg) 🧮. so 12+4*num bytes is the size of the low-delay RTCP feedback message in a compound RTCP packet 🎀
Measurements we defined two values to be measured 📏:
- Recovery time the recovery time is measured as the time between detecting a lost segment and receiving a recovered segment 😤. we measured this "recovery time" for each lost segment 🫶
- Waiting time the waiting time is the additional delay caused by the feedback limitation of RTP 🕰️
Figure 2 shows how a NEWPRED agent behaves when a loss happens 👀
the recovery time is approximated like this 🧠:
(Recovery time) = (Waiting time) +
(Transmission time for feedback message) +
(Transmission time for media data)so the waiting time is derived like this 🤓:
(Waiting time) = (Recovery time) - (Round-trip delay), where
(Round-trip delay ) = (Transmission time for feedback message) +
(Transmission time for media data) Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
a: Waiting time
b: Recover time (%: Video segments are lost)Figure 2: Relation between the measured values at the NEWPRED agent 📸
7.2. Simulation 🎬
we ran two simulations (Simulation A and Simulation B) 🧪. in Simulation A, packets get dropped at a fixed packet loss rate on a link between two NEWPRED agents 💧. in Simulation B, packet loss happens because of congestion from other traffic sources, i.e., ftp sessions 🚗💨
7.2.1. Simulation A - Constant Packet Loss Rate 🌸
the network topology for this simulation is in Figure 3 🗺️
Link 1 Link 2 Link 3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ +------+ +------+ +--------+
10(msec) x(msec) 10(msec)Figure 3: Network topology that is used for Simulation A 📍
Link1 and link3 are error free, and each link delay is 10 msec 🫧. packets may get dropped on link2 🙃. the packet loss rates (Plr) and link delay (D) are:
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}session bandwidth, frame rate, and the number of segments are in Table 9 📋
+------------+----------+-------------+-----+
|Parameter ID| bw(kbps) |f (frame/sec)| seg |
+------------+----------+-------------+-----+
| 32k-4-3 | 32 | 4 | 3 |
| 32k-5-3 | 32 | 5 | 3 |
| 64k-5-3 | 64 | 5 | 3 |
| 64k-10-3 | 64 | 10 | 3 |
| 128k-10-6 | 128 | 10 | 6 |
| 128k-15-6 | 128 | 15 | 6 |
| 384k-15-6 | 384 | 15 | 6 |
| 384k-30-6 | 384 | 30 | 6 |
| 512k-30-6 | 512 | 30 | 6 |
| 1000k-30-9 | 1000 | 30 | 9 |
| 2000k-30-9 | 2000 | 30 | 9 |
+------------+----------+-------------+-----+
Table 9: Parameter sets of the NEWPRED agentsFigure 4 shows the key values of the result (packet loss rate vs. mean of waiting time) 📉
when the packet loss rate is 5% and the session bandwidth is 32 kbps, the waiting time is around 400 msec 😬, which is just allowable for reasonable NEWPRED performance 👌
when the packet loss rate is less than 1%, the waiting time is less than 200 msec 💫. in such a case NEWPRED allows as much as 200-msec additional link delay 🥰
when the packet loss rate is less than 5% and the session bandwidth is 64 kbps, the waiting time is also less than 200 msec 🎀
in 128-kbps cases, the result shows that when the packet loss rate is 20%, the waiting time is around 200 msec 🌷. in cases with more than 512-kbps session bandwidth, there's no significant delay 🦋. this means the waiting time due to the feedback limitation of RTCP is negligible for NEWPRED performance 🫶✨
+------------------------------------------------------------+
| | Packet Loss Rate = |
| Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 |
|-----------+------+------+------+------+------+------+------|
| 32k |130- |200- |230- |280- |350- |470- |560- |
| | 180| 250| 320| 390| 430| 610| 780|
| 64k | 80- |100- |120- |150- |180- |210- |290- |
| | 130| 150| 180| 190| 210| 300| 400|
| 128k | 60- | 70- | 90- |110- |130- |170- |190- |
| | 70| 80| 100| 120| 140| 190| 240|
| 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- |
| | 50| 50| 50| 50| 60| 70| 90|
| 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 |
| | | | | | | | |
| 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 |
| | | | | | | | |
| 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 |
+------------------+------+------+------+------+------+------+Figure 4: The result of simulation A 📊
7.2.2. Simulation B - Packet Loss Due to Congestion 🚦
the configurations of link1, link2, and link3 are the same as in Simulation A, except that link2 is also error-free regarding bit errors 🧼. however, some FTP agents are also deployed to overload link2 🏋️. see Figure 5 for the simulation topology 🗺️
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
FTP Agents FTP AgentsFigure 5: Network Topology of Simulation B 🌐
the parameters are defined as for Simulation A, with these values assigned:
D[ms] ={10, 50, 100, 200, 500} 32 FTP agents are deployed at each
edge, for a total of 64 FTP agents active.the sets of session bandwidth, frame rate, and number of segments are the same as in Simulation A (Table 9) 💕
we give the results for the cases with 64 FTP agents, because these are the cases where packet losses could be detected to be stable 🥰. the results are similar to those for Simulation A, except for a constant additional offset of 50..100 ms 🫠. this is due to the delay incurred by the routers' buffers 🏠✨
7.3. Summary of Application Simulations ✨
okay so the big takeaway from all the NEWPRED sims 💅 the RTP AVPF profile's limitations do NOT cause feedback delays high enough to wreck NEWPRED's performance, for sessions from 32 kbps all the way up to 2 Mbps 🎀 the waiting time goes up when session bandwidth goes down and/or packet loss goes up 📈 and the reason for the loss barely matters, because congestion and constant loss rates behave pretty much the same 🙈 so for reasonable conditions and parameters, AVPF is lowkey perfect for carrying the feedback NEWPRED needs 🫶 if you want more on NEWPRED, check out [8] and [9] 📚
8. Summary 🦋
the new RTP profile AVPF got the full investigation treatment, both for performance and for any risks to network stability 🔥 we ran simulations in the network simulator ns2, covering unicast plus a bunch of differently sized multicast topologies 🌈 all the results are in this document 💜
okay network stability is a HUGE deal, so we had to prove the new profile can't cause a feedback implosion or hog more bandwidth than it's allowed to use 😭 we measured how much bandwidth RTCP used compared to the RTP session bandwidth, and it came out to more or less exactly 5% of the session bandwidth in every scenario we tried 💖 other RTCP bandwidth values can be set using the RTCP bandwidth modifiers in [10] ✨ we tested unicast with and without errors, multicast groups of different sizes with and without errors or congestion on the links, and honestly it all checked out 👑 so yes, the new profile is network-friendly 🫶 it only uses the RTCP bandwidth that RTP allows, and that's the whole point 💅
secondly (and this one's giving main character energy 🎀), receivers on the new profile get a real performance gain 🔥 we measured it by capturing how long the sender waits for the feedback it receives 😳 with the new profile, that delay can drop by orders of magnitude 🚀
in the third place, we looked at what the parameter "l" does to the new algorithms 🧚 spoiler: there is no magic optimum value for "l" 🙈 you can only get a trade-off 💀 how much it matters depends heavily on the environment, and you always have to balance the feedback suppression algorithm's performance against the delay you experience ⚖️ the value l=0.5 given in this document is the recommended one, and it seems reasonable for most applications and environments 🍓
9. Security Considerations 🔐
⚠️ this part is serious, bestie, so pay attention 😤
this document describes the simulation work done to verify that the RTCP timing rules from the AVPF profile [1] actually work correctly 🧐 because of that, any security considerations about those timing rules are covered in that document instead 📄
10. Normative References 📖
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.11. Informative References 📚
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Network Simulator Version 2 - ns-2, available from
http://www.isi.edu/nsnam/ns.
[5] C. Burmeister, T. Klinner, "Low Delay Feedback RTCP - Timing
Rules Simulation Results". Technical Report of the Panasonic
European Laboratories, September 2001, available from:
http://www.informatik.uni-bremen.de/~jo/misc/
SimulationResults-A.pdf.
[6] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology -
Coding of audio-visual objects - Part2: Visual", July 2000.
[7] ITU-T Recommendation, H.263. Video encoding for low bitrate
communication. 1998.
[8] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video
Coding by Dynamic Replacing of Reference Pictures", IEEE Global
Telecommunications Conference (GLOBECOM), pp.1503-1508, 1996.
[9] H. Kimata, Y. Tomita, H. Yamaguchi, S. Ichinose, T. Ichikawa,
"Receiver-Oriented Real-Time Error Resilient Video Communication
System: Adaptive Recovery from Error Propagation in Accordance
with Memory Size at Receiver", Electronics and Communications in
Japan, Part 1, vol. 84, no. 2, pp.8-17, 2001.
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.Authors' Addresses 💌
Carsten Burmeister
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: carsten.burmeister@eu.panasonic.com
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: rolf.hakenberg@eu.panasonic.com
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
EMail: miyazaki.akihiro@jp.panasonic.com
Joerg Ott
Helsinki University of Technology, Networking Laboratory
PO Box 3000, 02015 TKK, Finland
EMail: jo@acm.org
Noriyuki Sato
Oki Electric Industry Co., Ltd.
1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
EMail: sato652@oki.com
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
EMail: fukunaga444@oki.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
the legal bit, but make it cute 🎀: this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 💅
📜 the document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🌸
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights might be available, and it doesn't claim to have made any independent effort to find such rights 🤷♀️ info about the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗
the IETF invites any interested party to tell it about any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard 🙋♀️ send that info to ietf-ipr@ietf.org 💌
Acknowledgement 🫶
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖
📦 where this page comes from
- ietf: rfc4586 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms