I resisted the urge to resolve other issues with this, so there are a bunch of TODOs in the text. Most of the big blocks of text are moved from elsewhere in the document.
The guidelines overlap in odd ways. The first one is essentially TCP-friendliness, and I guess it's implied to be talking about "normal" wired networks. Then different guidelines say the algorithm should be evaluated with all sorts of environments and/or link parameters, presumably for friendliness. Then, in "Minimum Requirements" some of these are listed as mandatory to satisfy, and the rest as something the submitter has to report on, but the community may decide to accept even if it's bad. There are several different concepts that are being muddled here. Alternatively, we can structure it as follows: (A) Metrics to evaluate Does the new algorithm match its share of the existing bottleneck bandwith better than existing algorithms? (not underutilizing, not bufferbloating or congestion collapsing) in isolation or with multiple flows? Are flows using widely deployed algorithms not severely degraded by the introduction of the new algorithm? Is there a plausible incremental deployment plan? Something about short flows? (B) Mandatory Domains: must answer positively to (A) Wired networks, "normal" range of BDPs Wireless networks, "normal" range of BDPs (loss & jitter) Internet-scale deployment is sufficient for this? (C) Optional Domains: must evaluate (A) & report IoT Satellite Misbehaving nodes Response to sudden & transient events Tunnels for explicit-signal protocols Extreme packet reordering
I agree we need to restructure, I like the idea of A. I think defining heterogeneity in B is likely helpful - although we really ought to stop using "bandwidth" when we mean "capacity" - because it really confuses SDOs that actually do cap[acity v bandwidth tradeoffs:-) I'll fight that Internet-Scale deployment is sufficient;-). That plays to the big operators, and I do not like that. It worries me quite a lot that we target "normal BDPs" - that's not something I would welcome. It places all satellite outside normal, which again, I don't like - some satellite is definitely odd, but I'd really like to see broadband services as "normal", if nothing else, to include those people who can only use this technology. So, main question first: can we factor the last section as different in a particular perspective, rather than "labelling" networks as optional to support? i.e. XXXX is a property, and IoT is an example, transients and abrupt capacity variation is an example of radio networks; etc.?
I agree that we need a better structure. Including having actual subsections per issue, rather than the current list format. Two points: short flows, and transient events. Short flows are pretty much the norm, with reports of 90% of connections never going out of slow start. There is an associated problem: capacity discovery algorithm like slow start will rapidly increase the amount of data sent on a path, with a high potential for disrupting current users of that path. That's not good. There are potentials solutions such as quickly evaluating the capacity (e.g., packet pair, squirting, variants), remembering past connections (careful resume), or potentially getting input from the network (maybe something like Prague/ECN). These solutions have been explored for "special" links (satellite, deep space), but the problem is not just special links. I would like to see that discussed in the "main" section (A). Transients are also the norm. Congestion control is a form of control algorithm, and control algorithms must absolutely deal with transients. For example, if we deal with wireless, we need to deal with "entering a tunnel" -- and exiting. We may want to deal with . That should belong to the core (A), not the "weird configuration" (C).
Wait to land PRs, then do this with no substantive change, then do other PRs -- this change will be editorially disruptive.
I like the flow after this refactoring!Good to merge, the text here looks good to me. There are still things to think about, but these are probably best down on the basis of the entire document.


Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.


It closes the issue by explicitly stating the I-D describes two use- cases: One we know more about, one much less. There is no intention to add a range of other use-cases in between. I hope this calls out some of the issues and that new proposers could understand where they ought to evaluate.
MP variants of TCP and QUIC, as well as SCTP may see some deployments - should this document mention something aroud coupled congestion control vs. single path congestion control also?
Yes. But we should note that it is still in research.
I have mixed feelings there. If users have payed for a wireless subscription and a land line subscription, why should they not use the full capacity of both paths? I see the "selfish" case for proper scheduling, such as not sending delay sensitive traffic on a lossy path. But I don't see anything with the same moral level as "don't cause congestion" or "don't cause buffer bloat".
Discussed at IETF 117: Christian: Not enough info to make a recommendation Gorry: We should think about it Ian: Inclination is that we don't have enough information to make a recommendation Matt: Impact is no worse than browsers using multiple connections
Gorry will take a look if he has anything constructive to write here; if so, we will run the text by the community. otherwise, close with no action.
See PR for some initial text.
I am really not sure that we should say much about multipath at all, besides the minimum -- making sure that any use of a path is not worse than creating a separate connection on that path. In PR , Gorry is trying to separate "multipath for failover" and "multipath for load balancing". But these are only two points in the spectrum of things that can be done. For example, in various QUIC implementations, I have also seen: multipath of ACK -- using the lowest latency path to carry ACKs for the other paths, multipath of loss recovery -- resending the content of packets lost on path A on the hopefully more reliable path B, multipath redundancy -- sending duplicate traffic on path A and B, so the receiver can pick whichever arrives first, multipath redundancy with FEC -- same as above, but send FEC redundancy instead of merely duplicating traffic, multipath affinity -- subsets of application traffic are tied to a specific path as long as that path is available. Not all of these have obvious congestion control consequences, but some do. For example: Multipath of ACK is widely implemented, and the draft multipath specifically supports it. It is particularly useful when one of the links is high bandwidth and high latency. But then, this means the multipath connection will enjoy a shorter RTT than the other connections sharing the same bottleneck, which generally results in a larger share of the capacity. Multipath redundancy was pioneered by the QUIC team at Ali-Baba, as a way to get lower latency when sending video streams. They do that when one of the paths is considered a bit suspect. Of course, it leads to using more bandwidth.
This was intentional - Failover has been om the RFC series for sometime, and has been deployed. Concurrent multipath is something that has been on the edge for quite a while, but was at the other extreme - in the middle there are many things ... If you have an exhaustive list of the CC-related ones, that could perhaps be useful, I was avoiding making that list. I note FEC has interesting interactions with CC.
I wouldn't mind text that made it clear that "concurrent multipath" is a continuum of immature ideas. But Gorry is right that failover is well established and everything else involves hand-waving.
Regarding FEC and CC, it depends whether FEC is below CC or above it. With TCP, it has to be below, but with QUIC it is typically above, with FEC frames being controlled by CC like datagram or Stream data frames. I missed one interesting data point in the previous list, interactions between loss recovery and multipath scheduling.
Discussed at IETF 118: Asking for folks to take a look and comment here
Looks good.


Starting to unpick where equal access is important and where harm for others becomes important. If merged, this
Issue possibly related to , but more focussed on refocus away from a fairness evaluation. When a transport uses a path to send packets (i.e. a flow), this can impact other Internet flows (possibly from or to other endpoints) that share the capacity of any common network device or link (i.e., are multiplexed) along the path. In turn, this can result in variation in capacity, loss, or additional latency. Transports and network layer scheduling can be designed to offer fairness between sharing flows. This comes with both strengths and weaknesses - it can reduce collateral damage to other flows; but it also can motivate the use of additional flows to gain additional network resource. Transport proposals need to be evaluate and avoid inducing flow starvation to the other flows that share resources along the path they use. Transports proposals need to be evaluate and ensure they treat a loss of all feedback (e.g., expiry of a retransmission time out) as an indication of persistent congestion.
Gorry will start with a PR that defines the terms; then we can talk about what to emphasize.
Also is related
One of the guidelines is "Fairness within the Alternate Congestion Control Algorithm". This a great consideration, but behind that are quite a few problems. The classic fairness evaluation derives from the equation about asymptotic behavior drawn by Matt Mathis, which end up requiring a non linear response to the frequency of a control signal such as packet loss or ECN marks. There are of course two problems. First, time scale, because many connections don't last long enough to approach asymptotic behavior. Second, scaling, as discussed for example in RFC3649. If an algorithm requires ever increasing spacing between control events to sustain larger data rates, then the control loop becomes very long, or, in the case of packet losses very noisy as "true" control events get intermixed with random losses. In contrast, algorithms with linear response scale very well, but do not naturally provide fairness. Which is kind of a bummer, and also a research topic. I think the Bis draft will have to recognize that tension somehow, and encourage experimentation.
The Guidelines section asks developers of new congestion control algorithms to discuss the "Impact on Standard TCP, SCTP ], and DCCP ]." Maybe I am overly sensitive, but this way of discussing the issue feels dated, from a time when transport and congestion control where specified jointly. I think that ceased to be the case many years ago, for example with implementations of TCP providing choices between multiple congestion algorithms. (Indeed, DCCP itself provides a choice between two algorithms.) The Bis draft should probably present the issue differently.
Speaking of fairness, I also wonder if there is an accurate definition for it. There has been activity on the topic at the IETF (on in academia) : URL URL URL should this be discussed in the draft ?
Discussed at IETF 117: Matt: Replace fairness with freedom from starvation. Fairness only makes sense at low bandwidth. Christian: Not focus entirely at fairness, non-starvation goal is good. Gorry: Suggestion to put it in other draft, but not in this one Overall, get rid of it all together for now
In academia a next metric is to look at harm rather than fairness: URL
That's a pretty good reference, Mirja!
The reality is that Cubic has a horrific effect on the Internet: it is pretty efficient at building queues and making life terrible for others. The classic example is the parent busy on a video conference from home, and then seeing the perceived quality go down sharply because the teenager started downloading a movie... Which means I would take "fairness with Cubic" with a huge grain of salt. As is, yes, let it run and get some bandwidth, but make sure that it gets seriously penalized, so there is an incentive to replace it by something better...
A more serious problem is harm to tiny transactions using any protocol. They have to rely on timeouts for loss recovery. I suggest replacing this with absolute upper bounds on loss rates. E..g. see: URL Likewise for excessive standing queues, and to a lessor extent excessive CE marks.
Modulo the comments I've already posted, LGTMThe last changes by NAME probably mitigate my issues. I think we will have to come back to definition of harm and to the "self compete" part, but this is good enough for the next iteration of the draft.


Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.


rfc7141 partially updates rfc5033; include relevant sections in the -bis document
7141 does not mention 5033, so can you be more specific?
Oct 12: Pinged NAME to follow up
IIRC, it was due to rfc7141 updating rfc2914; rfc2914 is mentioned and referenced at numerous points throughout the 5033 document. 5033bis should heed the advice from 7141 around marking probabiliy taking into consideration packet sizes rather than only the packets themselves. At least this train of thought is the most likely one, which was had in my mind at the time.
Editors: we suspect that this question is orthogonal to the purpose of this document; will look more carefully at the reference.
It turns out that 7141 does have recommendations on response to congestion signals from the network, not just AQM recommendations (See Sec 2.3 and 2.4 for a good summary).


Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also. ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.


Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.


and .
Also
The text currently reads: "The community should also consider other non-standard congestion controls known to be widely deployed," This is a compromise to land a mostly unrelated PR. NAME doesn't think it's fair to expect participants to test algorithms that aren't fully specified. I would argue that if such specifications exist and the algorithm is systemically important, it absolutely should be modeled. Moreover, if the algorithm is rather loosely described, in many cases there is open source code (often in a Linux fork!) that can be tested on a host, or in simulation frameworks like ns3. If an algorithm is a true black box, with no description besides marketing material, and no open-source code, I agree there is not much to be done. I also believe that while algorithms like this exist, they are not systemically important to the internet.
gorry: ns3 code is not super high fidelity.
Discussed at IETF 118: There's a danger if you see a realtime flow that goes faster than a best effort flow, since realtime is usually constrained by other factors (potentially needing time to move forwards to generate more data) Seems hard to imagine that something not specified is able to place a burden on anybody else. If you want others to do a thing, write it down and document it. Of course, there is no protocol police: we cannot prevent people from deploying whatever they want. Can we provide a carrot for people to play by the rules: Could be a SHOULD consider requirements and how to interact We have: Guidance for people who are writing specs that aren't yet part of the community How do we evaluate those protocols How do we ensure that fairness can exist with these Need to have a commitment from this WG to help and not just throw up new requirements for data and for those bringing new CCs to engage positively. Perhaps spelling this out clearly NAME to file issue to write something encouraging for people early on in the document Christian notes that separate queues between realtime and best effort are not actually a strong requirement To measure capacity you do need some sort of queue, or else you cannot measure
This info RFC has some sensible guidelines on RTP feedback frequency, if we need this: "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences".
Related to
Condition (1) is concerned with the behavior with respect to Reno and, thanks to our edits, Cubic. But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.


I am not an IoT guy but I took a stab at it.
NAME do you have suggested text, or should I submit this is as a start and you can open a new issue?
Section 5.1 is just a TODO to write about this.
OK, that's a start. But there are two possible angles: could resource constrained devices use this spec? And, how would this spec coexist with IoT specific transports, such as "single buffer" implementations?Looks like a start (I fixed a typo). We don't speak about scale ... in that although the sending rate is often low (or short flows), the number of endpoints can be high.


Add some text to indicate that proponents don't need a complete report on all the criteria before coming to IETF. They can arrive having thought about these problems a little and have a willingness to do the work implied in this draft.
We need to be nice, but not too nice. This phrase is targeting folks like researchers or PhD candidates. They should be aware that this topic is not going to be a walk in the park. But showing why the problem is hard could also be an encouragement -- you don't get a PhD for solving again a problem that 100s have already solved...


Added the missing 'd' - thanks Neal.
I'm separating AQM from ECN, although ECN relies on AQM design and deployment - ECN can be a force for good when detecting bottlenecks and latency - aka RFC 8087.
Well, yes. ECN, by itself, is one of the signals that can be used by CC algorithms, together with packet loss, delay variation, and packet acks (input to bandwidth measurement). Makes sense to separate it. However, the L4S folks have introduced a tight coupling between a very specific use of ECN in the L4S AQM, and a fine grain mandate of the expected behavior of the CCA. And I cringe each time I read their dual queue formula based on the asymptotic limit of Reno -- but not Cubic. I wish we could walk that back, or describe it in more neutral terms. With L4S, ECT(1) is a signal from the sending host to the network that CE marks should be apply at incipient congestion, instead of waiting for actual loss-generating queue buildup as in RFC 3168. Maybe that should be true even for algorithms that are not described in L4S. Of course, we have to deal with what we have. Maybe we should just quote all the relevant RFCs, and denote the difference between ECT(1)/EC and ECT(0)/EC. Senders using ECT(1) should consider that the rate of CE marking signals the intensity of the congestion, while senders using ECT(0) should consider individual CE marks as denoting actual congestion.
I think the ECN text ought to approach with something very generic like setting ECT can provide nice properties [RFC8087], but comes with requirements for reacting to ECN-CE marking. This reaction to ECN-CE marks needs to be evaluated to ensure this conforms with the style of ECN being used. I'll make a PR.
see Neal's comment


Adding a scope that excludes multicast.
Uh, is a PR addressing the same issue -- you were supposed to review it?
Would if this variant is merged
Discussed at IETF-118. At least we can mention Sect 4 of Multicast UDP Usage Guidelines in RFC8085.
IETF 118: Possibility that we could rule this out of scope Also some interest in this as a separate document that comes after the -bis
So just to provide the background for my question. The Reliable Multicast Transport WG (RMT) did produce two expermential congestion control specifications for multicast: So these specifications exists. Most mulitcast deployments are done in controlled environments however, with [Automatic Multicast Tunneling] (URL) multicast traffic these days have more probability to occur across links where this traffic would share bottlenecks with other unicast traffic. However, this amount of traffic is still normally bit-rate bound so it might be considered just in-elastic and consuming the bit-rate it does. I also want to state that I am fine with declaring multicast out of scope, but maybe some information about that there exist algorithms should be includeded in the draft. So an explicit out of scope with some background section/appendix.
We will put it out of scope and point to RFC 8085
Sorry, just reading through these changes now -- Why does a PR on multipath close an issue on multicast? Am I missing something here?
Whoops, that does not seem correct, re-opened this issue.
To answer NAME more directly, I don't think this draft is in the business of listing algorithms unless it requires new proposals to be measured against them, and not even that if the topic is out of scope. 5033bis is not a congestion control tutorial.
NAME I think it is a question of how one resolve this and if one declares it out of scope. Are we explicitly stating something like this: Multicast congestion control algorithms is out scope, and the rules and requirements within this specification has not been evaluated on their applicability for multicast congestion control. Future work on multicast congesiton control to specify new algorithms or update existing [webrc][TFMCC] will have to evaluate what is applicable and if additional requirements are necessary.
Add a changelog item (as in ) and it LGTM.


Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class. In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")


If merged this
Our abstract starts: "The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks, wireless technologies such as 3GPP and WiFi, long distance satellite links) and also in conflict with the needed, more isochronous, behaviors of VoIP, gaming, and videoconferencing traffic." ... is it just me, or does "inadequate" and "at conflict" seem an odd BCP statement from the IETF itself.
Agreed. How about something closer to: "The IETF's standard congestion control schemes have been shown to have performance challenges in various environments (e.g., high-speed networks, cellular and WiFi wireless technologies, long distance satellite links) and also for interactive traffic workloads (VoIP, gaming, and videoconferencing)." cc: NAME NAME


Suggested AQM text to address issue, when merge will
This section is listed as a special case, which it is (kind of), but it seems rather out of place in that section - I think we might wish to move it to the previous section. Since the original BCP, AQM is more common and really ought to be considered in any new design - even if the design does not wish to optimise for this.
Previously discussed in
Editors 1/16/24: Just add a sentence that AQMs are hard to detect, and therefore must be thought about -- cannot just ban use of a CC with AQM. But this falls thematically in with the special cases.
AQ are only a problem if they introduce unexpected behavior. The classic example is rate limiting, for which BB had to introduce special code.
Although packet scheduling and policing are useful complimentary functions, I don't think they are AQM.


eliminate some awkward/unnecessary phrases. Include brief rationale for a bis.
done
OK, how about now?


Sec 2 leans heavy on the dated example of Highspeed TCP and drives pretty much everything to Experimental "until such time that the community better understands the solution space." It says that experimental RFCs can either be those judged to be safe on the internet, or those intended for testbeds. At this point, we probably understand enough to allow proposals to go for Proposed Standard. The safe/testbed distinction also doesn't make sense -- we might want to standardize CCs for controlled environments, like DCTCP. This needs a complete rewrite. It wouldn't hurt for that rewrite to also note that the IRTF is another venue, non-normatively.
I think a rewrite would help, but I'm think that could be too radical - we still do have proposals that ought ton be EXP either until deployment experience; or until we can agree they are "safe" for more general use. That doesn't seem to be a problem to me, but we ought to allow PS also. I agree we ought to mention IRTF.


Also eliminated obsolete/redundant discussion of AQM.
We missed a TODO in "Wired Networks"
Approved. Is "As" really "Because" ?


(Contributing text as an individual, chair hat off) Here's some initial proposed text based to Please feel free to tweak my proposal.
Very nice. Looks good to me. Thanks for this!
The Introduction correctly points out the following: The above text says guidelines for specifications are important, but such guidelines only make sense if there is a specification in the first place. So I wonder if it's worth saying a few words here about why it's useful to specify/standardize congestion control algorithms. A few thoughts on the benefits of specifying congestion control algorithms: Help get a shared understanding between implementers, operators, and other interested parties of how the algorithm works and how it is expected to behave (or explicit discussion of parameters and such which can lead to differences in behavior) As a result of the shared understanding: Make it easier for anyone, not just the initial proponents or main implementers, to point out current issues/limitations or suggest improvements of a spec that is still in development, and make it easier to converge such changes to a consensus behavior There may be more benefits. Though I wonder how to best capture the nuance of "Some documentation or artifacts are better than nothing, but an actual spec is better than just a snapshot for documentation or artifacts". Do people think it'll be useful to add something along these lines to the document?
I agree it would be great to add this to the doc, and agree that those two bullet points would be good to integrate. Another more specific benefit that may make sense to add: due to the constraints of open source licenses, some implementors have noted that in some cases they are unable to read open source reference implementations; in such cases it is important to have a detailed spec of the algorithm that is unencumbered by open source license constraints.
I can see this would be of value to someone considering submitting a proposal. It also may help them to justify the effort in writing this down. If we can find words that work, I'd like to consider adding something on this.
Guidelines on what to consider are good for anyone (those who design, those who implement and those who document). The only place where guidelines could be used for enforcing something is where people wish to have congestion control algorithms published through the IETF. But that doesn't make them useless in other parts of the process. (My friend who does CC for realtime media is developing his work through iterations of code, not iterations of documentation. Guidelines would still be useful for him.)


Minor proposal: the leading sentence in the second paragraph of the section "Mixed algorithm" could be made a bit easier to read.
I think we can merge


The current draft allows tracks within a catalog to be updated. This causes a few problems: What happens if a track is changed (ex. new profile)? When does this update occur? What happens when the catalog update is delayed? If the publisher changes the codec/profile in the middle of a track, the decoder will blow up. There's no way to know when the change will take place.
I don't see how we could easily support tracks being updated. At the very least we would need a group ID when the change occurs, but that won't work in the face of packet loss, because the catalog update could arrive after the starting group. I think the only way to fix this is to put the init information at the start of each group (ex. SPS/PPS) which is not desirable. I would prohibit it for now. At the very least, some text to say that the init payload MUST NOT change on subsequent updates. We can only add or remove tracks.
IMO we start with no catalog updates for interop. Then we can build an ADD and REMOVE track message to avoid retransmitting the entire catalog on each update.
NAME By 'update', I agree that we shouldn't allow their media characteristics (anything described in the init segment or the init itself) to change. But we should allow them to be added and deleted . Agree I think that having no catalog updates in v1 is unnecessarily restrictive and would lead to missed use-cases, rather than better interop. We also don't need to invent ADD and REMOVE track messages if we allow the CATALOG (and its updates) to define the availability of tracks. The whole purpose of the CATALOG track is to do exactly that. This point is up to MOQ base protocl however and we need to resolve it there. And "avoiding retransmitting the entire catalog on each update" can be addressed by either ignoring (because catalog updates are small to begin even with their init payloads), or by allowing delta updates on the catalog, which wouldn't be complex and I can mock that up if you'd like to see what it might look like?
Yeah, the ADD and REMOVE messages would be delta updates. I think we need some timing information about when a track starts and ends, although I'm not sure.
Discussion 4/20: Need to add a delta update mechanism Same group, second or subsequent object Each object is a list of delta updates. Sync'd tracks should be added in the same object. Some text to instruct player to process all available tracks before performing track selection.
Also, if removing track, publisher should send remove along with a last Group, Object number. Update with all tracks removed signals EOS.


Changing name to draft-law-moq-warpstreamingformat to match consensus at last authors call.


Modifies document to reference external CMAF packaging draft. .
As proposed in , I think we can simplify the mapping: To clarify: There are any number of frames in a chunk (moof/mdat pair). There are any number of chunks in a fragment (styp and moof/mdat pairs). There are any number of fragments in a segment. (concatenated together) A fragment* is independently decodable. In order to minimize latency, there should be a chunk per frame, which is the same recommendation as LL-DASH. If the object has a length in the header, then there should be a chunk per fragment too, but I desperately want to avoid that. That way there would be no latency impact for using a single OBJECT for the entire group.
The catalog object has to be more than just a CMAF header, since it must described multiple tracks and also communicate their subscription names. On the GROUP and OBJECT mapping, I agree. The core requirement is that a sequence of OBJECTS is independently decodable if the client starts with the first object in a GROUP. This is satisfied with the restriction that a Group marks a fragment boundary, which is also satisfied by saying that the GROUP MUST represent a segment boundary, since each CMAF segment holds one of more fragments. COnsider the case of a 2s GOP at 30fps. The first OBJECT holds an I frame, the rest Ps. It would be compliant to mark a new GROUP every 30 Objects. It would also be compliant to mark a new group every 60 objects, which is the equivalent of transmitting a 4s segment comprising 2x2s fragments.
As an outcome of the discussions at ETF 117, I wrote an ID to describe how CMAF packaged content can be utilized with moq-transport. This ID is available here URL The WARP draft needs to be updated to reference this CMAF packaging draft.


This PR adds a definition for a timeline track format, along with details about how to identify timeline tracks in the catalog and how to update timeline tracks. and
I like it! Regarding "The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group." it means that the first object of the group strictly inflates with time. For an open range track (for example a 24/7 video channel), it may become excessively long. We may allow summarization of old times in the timeline csv.
A special ‘timeline’ track is produced which describes the availability of groups and objects with respect to media time and wallclock time. May also carry media time events which can be used by the player in constructing a UI, for example “Goal”, “Penalty”. This track can be used by the player for seeking to request specific portions of a DVR window in a live stream, or to any portion of a VOD asset. This may be used for advertising insertion at a later date. In the proposed structure below, the metadata field may be empty. If present, it must be enclosed inside double quotes and may hold any string data. In this example, JSON and XML metadata entires are shown.
I like the idea. Note that some have advocated for KLV as the support for timed metadata for live video. Here is a Demuxed talk about it a couple of years ago URL


The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.


Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.