Citing Experimental RFCs as if being a part of CUBIC #90
Comments
|
These references are all informational, which means they are not DOWNREFs by definition (see RFC3967). Propose to close with no action. Markku? |
|
No word from @markkukojo, closing this. @markkukojo, please reopen if you disagree. |
|
Right, the references are currently informal but I think the issue is more subtle and how some of the experimental RFCs are now cited puts them into a "grey area" . Sec 4.10: A solution to this could be simply to say: "CUBIC MUST employ a slow-start algorithm [RFC 5681]." I understand that the problem here is that if one decides to use [HR08], one needs to take that into account when setting W_max , etc. as described in the draft. However, I'm not sure whether it's reasonable to allow (by using MAY) employing an algorithm in a research paper (or in an Exp RFC) as part of a Stds Track RFC? My interpretation of using MAY in this way is that it sends a message that "while the cited algorithm is experimental (or research) only and should not be used in the public Internet other than for experimental purposes, it is, however, ALL OK to deploy it when used with CUBIC". So, instead of using MAY, the draft could simply say that "if CUBIC uses [HR08], it may exit ..." Sec 4.9: Here also the use of MAY is quite unnecessary and potentially results in similar confusion about the status of RFC 3708. Again, it would be just enough to note that if any of these are used, the mentioned CUBIC variables need to be restored as described. However, the authors should carefully consider what RFC 4015 says and what limitations there are for a congestion control response when a spurious RTO is detected. RFC 4015 is currently the only Stds Track CC response algorithm for spurious RTOs. There is no Stds Track CC response algorithm for false Fast Retransmits; this topic was studied around two decades ago and there was no consensus on whether restoring CC state is a good idea in all scenarios. E.g., in mobile networks, a make-before-break handoff from a high RTT path to a low RTT path may result in packet reordering when the available network capacity actually decreases and restoring the old state in such a case is not a sane action. Therefore, I think that this draft is not in position to provide a reasonable suggestion to unconditionally restore CC state after spurious congestion events nor to provide evidence that it is always the correct action. Moreover, handling spurious retransmissions is not a key part of CUBIC but it is a more general issue where other CCs have the same challenges as CUBIC and therefore I think the CC response for spurious rexmits should be handled separately and should follow common principles for all CCs. Sec 4.6: The draft allows using RFC 7661 as described in the RFC. However, if I recall it correctly, the equations in RFC 7661 assume that cwnd increase and decrease uses standard methods i.e., alfa=1 and beta=0.5. If the equations in RFC 7661 are directly applied with CUBIC, the outcome might not be expected nor correct. I didn't have time to check this, so I might be wrong, but this is good to double-check with Gorry and/or other authors of RFC 7661 who have better insight to the details of RFC 7661. |
|
Please check #90, which intends to address your first two comments. About RFC7661, would @gorryfair please chime in? |
Response to spurious events due to Fast retransmits was added newly to 8312-bis draft as it made sense to cover this scenario which is likely more common than spurious RTOs and folks who implemented QUIC noticed a great throughput improvement when implementing this. I agree that this is common to all CCs but at as of today, I don't think any RFC covers it. For completeness, it made sense to add it to CUBIC.
How common is the scenario you are describing above? And if we are switching to low RTT, then the sender will soon-after reduce the congestion window if restoring to old state was a mistake. (i.e. if the old state cwnd > capacity for low RTT path) |
Regarding RFC 7661, there are two things to consider,
I don't know how to best document this, should we re-write these equations and explain all the variables or is there a way to reference RFC 7661 and just say, If you use RFC 7661, CUBIC updates Section 4.4.1 of RFC 7661 to replace the 0.5 reduction factor by Beta_cubic? |
|
The latter seems easier to me, but I don't have a strong preference. Waiting to hear from @markkukojo and/or @gorryfair. |
|
I'd like to merge #111 soon. Is there anything that needs to be changes in it to address this issue? |
|
I'll take a look at it later today. |
Let me try again. There are several reasons why the existence of the current text is problematic:
The scenario above is just one example. I don't have an answer how common it might be today. AFAIK at least cellular networks used to attempt delivering data in order up until 3G. Don't know that well what is the exact situation with 4G and 5G (or 6G). But if one would like to propose reverting CC state in case of false fast retransmits one should provide evidence that such scenarios are non-existing today and unlikely to (re)appear in the near future. E.g., is there evidence that route fluttering does not exist anymore? Moreover, there have recently been proposals which suggest that link layers should not anymore deliver data in order. E.g. Bob has been advocating it. How about if it gets realised anytime soon with some technologies? Sure the sender will reduce the congestion window if restoring to old state was a mistake, but the new available capacity might be only a small fraction of the old and it would possibly require reducing cwnd a notable number of times before cwnd decreases enough. And such a sender behaviour would be detrimental to other flows from which it would steal the bandwidth unfairly. |
Has this been implemented for CUBIC and experimented with so we know it works properly? And do we have data to show this is the case? In other words, would this be mature enough to become Stds Track and just for CUBIC, while RFC 7661 is experimental and the problem space once again is not specific to CUBIC but common for all CCs? Anyway, I'd like to hear from those who have worked with RFC 7661 and do have a lot of experience on it. And would definitely have much better insight in any potential caveats that might be buried in there.
IMO this problem space is common to all CCs and still experimental, so the proposal is not mature enough and best handled in a separate document, either RFC7661bis or a draft of its own that may potentially be incorporated in RFC7661bis later. |
|
@huitema @nealcardwell In this issue #23, we discussed and added a new section for Spurious detection and response for CUBIC but @markkukojo doesn't think we should do that due to any adverse effects of reverting to old_cwnd in case there is route change that has much lower capacity than old_cwnd state. Do you think citing RFC 4015 for spurious RTOs is enough? This would mean we wouldn't provide any guidance for spurious detection of false fast retransmits. |
|
It has been experimented -- was the default option for using cubic in picoquic, before switching the default to BBR. No negative feedback. There were also extensive simulations done by the MS Quic team, as part of their systematic unit tests. We should ask them, but I believe these simulations are based on scenarios they have encountered in real deployments. Implementing spurious loss recovery in QUIC-Cubic was key to achieving parity with TCP-Cubic in these scenarios. Links are not perfect, spurious reordering do happen -- that's quite visible on Wi-Fi and LTE links. I also saw some networks aggressively bundling the small UDP packets that carry QUIC ACK. Some networks will send small and large packets with different priorities. All that means that the standard recovery algorithm sometimes results in spurious loss detection. Cubic is not performing well in practice without spurious loss recovery. If this is not specified, implementations will probably just move to use BBR instead of Cubic. There is a perverse bad angel whispering to me that this would be a good thing, since BBR does result in smaller queues all over the Internet. Which means I am a bit conflicted... If you are concerned about standardization status, one possibility would be to move that text to a non normative appendix. |
I would strongly urge the draft to keep the "Spurious Congestion Events" section, since reordering and spurious retransmits are common and getting more common, so undo of CC reductions is critical and becoming more so. In the scenario mentioned that has a route change that causes a reordering event and reduction in available bandwidth, it's still fine to undo based on detecting the spurious retransmits. If there are real losses at any point, those will be detected and the CC will react. The likely order in this scenario would be:
I would suggest citing all the major mechanisms that major TCP stacks use in the real world to detect spurious retransmits, namely something like: "CUBIC implementations MAY use any of the following documented mechanisms for detecting spurious congestion events: Eifel [rfc3522] [rfc4015], F-RTO [rfc5682], DSACK [rfc3708]." I believe their statuses are:
Really TCP stacks SHOULD use these, but if there's a problem with a stds track doc saying a stack SHOULD use an experimental RFC then perhaps MAY is OK? |
|
If we want to say "MUST implement" for something that is not on the standards track, maybe that's a reason to republish that document as a PS. Which documents specifically would this be the case for? |
|
I was wondering why is Eifel detection (RFC 3522) experimental while the response on detection (RFC 4015) a stds track. Should we say, |
|
IIRC, RFC3522 has an IPR disclosure that makes it difficult to implement in open source or otherwise. RFC4015 has no such IPR. The community at the time felt strongly that the IPR meant RFC3522 shouldn't be standards track. Pasi developed F-RTO in part because of the IPR in RFC3522. |
|
Note that as far as QUIC is concerned, detecting spurious RTO is completely straightforward. QUIC packets have unique numbers, any data that need to be repeated is carried in new packets, with numbers different from the initial transmission. The sender just has to record an ack of a packet that was considered lost, there is no requirement to implement F-RTO or other algorithms. |
|
Heads up: I plan to merge #111 soon, unless I hear objections. If you do object, please make a concrete rephrasing proposal (on the PR). |
Thanks Christian for the data point. Just wondering whether route fluttering was included in the test cases?
Sure, links are not perfect. That's why these algos were brought to IETF some two decades ago. At that time maybe the hardest thing for us was to convince that spurious rexmits are a real problem ;) There was quite a bit lessons learnt in that exercise on those days and it would be good to not ignore it all. Much is documented in those RFCs but not all, e.g., response to spurious fast rexmits never materialised. A correct response (UNDO) should not just simply restore previous state but consider various issues like adjusting DupThresh (or RACK reorder wnd) to avoid further spurious rexmits, control possible bursts due to UNDO, and other safeguards (see more in a latter comment). In addition, all this requires experiments in a range of environments to make it an experimental RFC, not to mention Stds Track. |
Please note that RFC 4015 is a stds track response algorithm for spurious RTOs. The question was why the advise in RFC 4015 is wrong and why this draft would need to modify it as the current text does and thereby maybe requires to update RFC 4015, instead of pointing to RFC 4015 as the response algo for spurious RTOs and just giving the extra state that needs to be stored/restored? |
|
@markkukojo could you explain what changes you would like to see in #111 or what is missing from it? |
Yes, I think IPR issue is one reason but not the only one. There is much in those RFCs so my apologies for not opening it all when I said there are caveats. AFAIK, another reason why RFC 3522 (and RFC 3708) is not Std Track is that it is vulnerable to lying receivers that can easily make a fast rexmit to appear as a spurious rexmit. There is a mitigation proposed for Eifel detection but it calls for experimentation that we do not have AFAIK. As Ack supression is deemed to be quite common today, such experimentation would be even more crucial to show that it works appropriately. Without a safe detection for fast rexmits it is hard to propose a response. As Christian noted, QUIC is much more straightforward in detecting spurious rexmits, so should not suffer from similar problems. |
Text for Slow Start section: ssthresh {{!RFC5681}}. Reasoning:
For spurious rexmits: I cannot provide text as I have expressed my strong opinion:
I'd suggest to move the text in sec 4.9 to sec 5.3 (Difficult Environments): |
|
Re: "Much is documented in those RFCs but not all, e.g., response to spurious fast rexmits never materialised."... Even if RFCs for responding to spurious fast retransmits never happened, the code to do that has been widely deployed and used in the Internet with good results, including at least in Linux TCP for over a decade. Since implementations are doing it, we may as well tell them how to do it well. :-) Re: "That's why I think it is not the best option from the process point of view to embed a response to spurious rexmits in this CUBIC spec as the problem area and solution is common to all CCs."... The solution is not common to all CCs, because the state variables for each CC are different. It is important for the CC spec to specify which variables need to be saved and restored if there is an undo event. That's why it's great that 8312bis covers those details. I agree the question of whether/when to undo a fast recovery is a separate question. But that's why this 8312bis is referencing other docs to cover that. |
... @markkukojo, so that entire paragraph should look like the following?
IIRC one pragmatic reason is that there is no other standards-track mechanism.
This sounds like you are arguing that text should be taken out of the document - which bits?
Again, this sounds like you are arguing that text should be taken out of the document - which bits?
First, I thought spurious RTOs and fals RTXs are not uncommon on general Internet paths. So I'm not sure that moving that text into a section called "difficult environments" is appropriate. Second, it sounds like you don't just want to move the existing text, you are outlining an complete rewrite of what we have. It would be more actionable if you could propose a draft of the concrete text you think should be there (ideally, as a PR.) |
* Rephrase text around algorithmic alternatives. Fixes #90. * Add HyStart++ * Fix spacing * or -> and * Update draft-ietf-tcpm-rfc8312bis.md Co-authored-by: Lars Eggert <lars@eggert.org> * Update draft-ietf-tcpm-rfc8312bis.md * Incorporate suggestion from @bbriscoe, and strengthen rec for HyStart++. * Update draft-ietf-tcpm-rfc8312bis.md Co-authored-by: Vidhi Goel <goel.vidhi07@gmail.com> * Update draft-ietf-tcpm-rfc8312bis.md * Update draft-ietf-tcpm-rfc8312bis.md Co-authored-by: Vidhi Goel <goel.vidhi07@gmail.com>
No. Sorry, I meant with the three dots (...) that I modified the beginning of that para and the rest of the para may remain untouched. Please, see below for the full text. CUBIC MUST employ a slow-start algorithm, when cwnd is no more than If CUBIC uses HyStart++ {{!I-D.ietf-tcpm-hystartplusplus}} for early I also tried to explain why the draft cannot say "in general SHOULD use HyStart++ ...". HyStart++ is specified for the initial slow start only! You cannot require it to be used e.g., after a timeout when CUBIC like any other TCP CC algo must use RFC 5681 slow start as there is no other slow start specified for that purpose. Same holds for the other cases where cwnd < ssthresh. Furthermore, the current text effectively says (claims):
My apologies but I don't understand this reasoning. If something is stds track, it is not a reason to make it automatically a SHOULD. For SHOULD (and MUST) there needs to be a reason why it is required and it needs to be explained. What beaks if CUBIC does not use HyStart++?
Sure, spurious RTOs and false RTXs occur. But how often, in what conditions, what are the reasons, what else may happen at the same time? We need evidence (well analysed measurement results) that it is common and that we understand the reasons for such behaviour and hence are able to justify a correct way to do the response. Currently there is nothing in this draft about these. Moreover, what could be done to avoid such spurious rexmits, what actions the IETF has taken/should take to advise how to avoid them. Is the transport protocol the only actor that should be prepared and react? What we need to take into account if we undo cc state and how the state is safely restored? All these questions are specific to the problem area of spurious rexmits but not specific to CUBIC. Undo involves a congestion control decision and as far as I remember IETF has never accepted a Stds Track RFC for congestion control actions without any evidence that demonstrates that the proposed cc actions are safe and correct. Why should this draft make an exception? Please see my reply to Neal concerning whether cc actions as currently proposed are safe and correct. If the problem is shown to be common, then the text may better belong to sec 5.4 (Investigating a Range of Environments) than a section about difficult environments.
Yes, it requires much more consideration and analysis than the current piece of text in this draft. In particular, if one wants to specify a new mechanisms to restore state or a mechanism that deviates from the one for which we have a stds track specification (RFC 4015). |
Yes, UNDO has been there in Linux well be before CUBIC was invented. But UNDO being implemented in Linux does not alone provide any evidence that doing UNDO like rfc8312bis proposes is the right way to do it. ;) I fully agree that it is important to tell how to restore cc state "well" but the problem is exactly that this draft does not do it now. In other words, you are saying and supporting that it is all ok to a) blasts a full cwnd worth data at line speed,
Sure, I am not objecting to specifying which variables need to be saved and restored in addition to those that the existing RFCs already do and what is common to all CCs. But what I try to say is that this is the quite trivial part of the cc response to spurious rexmit. I'm objecting that this draft modifies RFC 4015 response to spurious RTOs such that after the undo a) the TCP sender blasts a full restored cwnd worth of unnecessary rexmits at the bottleneck It would be helpful for the discussion if everyone would read RFC 4015 and the related RFCs and compare what they say to what RFC8312bis says. |
|
Could you propose a PR that would address your concerns? I think we'll keep missing things otherwise. |
That's a separate problem. Restart from idle does that as well. TCP implementations should use pacing to solve this problem of blasting full cwnds. Pacing is the only complete and general solution to blasting full cwnds, and it's orthogonal to CUBIC.
That's an orthogonal loss recovery issue, and belongs in a separate document focused on loss recovery. For example, the RACK RFC covers this kind of issue. It doesn't make sense to put this in a CUBIC document, because the CUBIC document doesn't know whether
Interactions between lying receivers and the detection of spurious loss recovery episodes are a loss recovery issue, not a congestion control issue, and belong in a loss recovery document.
Most of the issues you are bringing up are loss recovery issues, not congestion control issues, and should be in a separate document, IMHO. IMHO the 8312bis is a CC document, and should effectively say something like: "if your loss detection algorithm detects that a previous loss inference was spurious, then the CUBIC CC response is X".
If the loss recovery has been undone, the sender is not in a loss recovery state, and thus would not retransmit anything.
That's an orthogonal loss recovery issue about how to adjust the RTO calculation based on an undo even, and belongs in a separate document focused on loss recovery.
That's an orthogonal loss recovery issue about whether undo should happen, and belongs in a separate document focused on loss recovery. |
|
I read RFC 4015 and agree that it does cover all the safety requirements for restoring / undoing the congestion control state and how to update the RTO to further avoid spurious timeouts. So, it covers both updates to loss recovery and congestion control. As a developer for QUIC spurious retransmit detection, congestion window restoring and changing the packet (dup ACK) and time threshold for loss detection, handling of special ACKs (CE counts), I do agree if all the responses to a spurious retransmit were in a single document, it would have made my life a bit easier. So, it might be a better idea to remove this section (section 4.9) completely. |
|
If we do this,
|
|
No, I don't think we need to cite anything. Folks who would want to implement Eifel response would follow RFC 4015 |
|
We added that section in response to #23, and there was quite a bit of discussion and support for it. It seems odd to go back on this now? |
|
I know but what we added is trivial (reset the state to previous state). |
|
OK. Could we get some others to chime on on removing this section? If there is consensus, I'll do a PR. |
|
I strongly advocate to keep Section 4.9, "Spurious Congestion Events". Some responses to Vidhi's comments:
It seems trivial once you write it down, but it's not obvious to implementors. The Linux TCP CUBIC code has had undo for a decade, but the undo of CUBIC is still incomplete and buggy because it only restores cwnd and ssthresh, not the CUBIC-specific values. Yuchung and I noticed this years ago, but didn't have development resources to fix it given that our team had moved on to a different congestion control algorithm. So one of the widest-used CUBIC implementation is still getting undo wrong. Yuchung and I were planning to resurrect and finish our in-progress patch to fix this to match 8312bis when 8312bis settled down. But if 8312bis omits this then Linux CUBIC undo and other implementations will lose momentum and/or fail to get it right. Even just specifying the set of variables to restore is hugely valuable, and will save the world from having more buggy implementations like Linux TCP CUBIC.
The 8312bis section on undo doesn't need more work, IMHO, because this draft doesn't need to specify everything that a TCP stack needs to do to handle undo events; it only needs to cover what CUBIC's response to an undo event should be. Even if someone later writes a new RFC that tackles spurious retransmits, it doesn't make sense for that future spurious retransmit RFC to specify all the variables settings that every IETF-documented CC algorithm (Reno, CUBIC, DCTCP, etc) should make upon undo events. From a protocol specification and software engineering standpoint, we should try to strictly separate loss detection/recovery (including detecting spurious retransmission events) from congestion control (including how to undo a congestion response, if the loss detection module decides to undo). In software engineering terms, loss recovery drafts should cover whether to call cc->handle_loss() and cc->handle_undo_loss(), and this rfc8312bis should cover what cc->handle_loss() and cc->handl_undo_loss() do.
What is proposed is quite methodical and sufficient as far as CUBIC CC goes. Loss detection/recovery should make its own specification for what the loss detection/recovery algorithm need to do upon detection spurious recovery events, which the RACK RFC already does (spurious loss recovery events raise the reordering window).
All the existing algorithms or detecting spurious loss recoveries (FRTO, DSACKs, Eifel TS-based undo) detect spurious loss recoveries in 1-2 round trips, so in practice the link conditions change very little. Just restoring the CC algorithm state to what it was before the spurious loss episode is excellent in practice, in our experience looking at real-world traces on YouTube, google.com, and internal RPC traffic: it's simple and robust, and far better than not undoing at all, given that reordering is not rare, and will likely become more common over time. If link conditions have changed and available bandwidth has decreased, then in practice the flow will see loss/ECN soon, and slow down. But in practice when there are undo events this is usually due to radio layer delay fluctuations or reordering, not due to sustained reductions in available bandwidth. |
|
I agree with @nealcardwell that it is better to keep this subsection, as we have noticed that several issues/bugs (not just cubic) are/were related to the undo component. We do not need to specify when to undo, but instead specify which variables to undo. |
|
Thanks. Then @markkukojo needs to be a bit more specific about what changes he would want to see in the section to address his issue. |
|
My sincere apologies again not being able to respond earlier (unfortunate force major for me). About slow start start text in Sec 4.10: I've already suggested text to replace the current one and explained the rationale. Please see draft-ietf-tcpm-hystartplusplus, Sec 4.3: The problem with overshoot and the MD factor to use is present in the RTO recovery as well because a pkt loss may be detected before cwnd reaches ssthresh (even though HyStart++ suggest differently). Please see shortly my reply to Bob in #85 where I clarify this further. |
|
About spurious retransmissions and response to such events (Sec 4.9): I agree with Vidhi that the issues and the response to spurious rexmits is not that trivial. I also agree with Neal that the issues related to response I listed belong to another document. However, Neal suggests for some reason that those issues are loss recovery issues which sounds very weird to me. We are discussing spurious rexmit detection and response when such event is detected; when a spurious rexmit is detected there is no loss recovery by definition because detecting a spurious rexmit avoids/terminates loss recovery. Instead, this topic was extensively studied and considered at the time of writing RFC 3522, RFC 5682, RFC 3708, and RFC 4015. The IETF decided to handle spurious rexmits by separating the detection and response in separate documents and it is the current IETF consensus as documented in these RFCs. The decision was to not include any response actions in the detection documents but to put all actions related to response in the response documents. These actions include congestion control actions and any other actions that were considered important for a sender to take. This of course is not the only possibly way to organize RFCs for handling the issues, but it is what IETF currently has agreed on. We may change this but it requires someone to volunteer rewriting all these documents. The response actions are currently documented in RFC 4015 for detected spurious RTOs. AFAIK IETF has never accepted a standards track RFC that modifies existing congestion control and/or related important actions without appropriate experimental data to support such a change. AFAIK nobody has presented any data for discussion in TCPM wg that would support ignoring/modifying RFC 4015 response. Maybe chairs can clarify whether this is the case? IMO the only thing that this draft is subject to present w.r.t. response to a spurious RTO is the additional congestion control variables that needs to be stored/restored for CUBIC, that is, W_max, K, epoch_start, and W_est. I am happy to suggest text for this, if we can agree on this. For spurious fast rexmits we do not have a response RFC for various reasons that I have tried to explain and do try to clarify here further. First of all, again, it is not that trivial as this draft suggests and Neal seems to think. When a false rexmit is detected there are various different scenarios that require different handling and the response also depends on the detection method used. I believe that Neal mainly considers using DSACK-based detection? If DSACK is used, the fast recovery is over and all related ACKs have been received when the decision is made, i.e., there should not be any data segments in flight that were injected during the fast recovery. In this case the response is much more trivial and more closer to what this draft suggests. However, using RFC 3708 to detect false rexmits and applying an UNDO CC response to is not ready for standard track for security reasons! There is no working solution for RFC 3708 algorithm against lying receivers, meaning that it is very easy to device a TCP receiver that avoids cwnd reductions in case of pkt loss! TCPM chairs would need to address this in their writeup and I would be suprised if such draft would pass SECDIR review or actually I would expect TCPM not to decide forwarding such proposal for publication. If Eifel (RFC 3522) is used to detect false rexmits, the response must be more complex, because there might be a half a window worth spuriously rexmitted data segments in flight when Eifel detects the spurious false rexmit. That is, a trivial case where the reordering extent (distance) is small (just enough to trigger a false fast rexmit) and maybe one or a few segments only got reordered (delayed). In such a case, a new ACK arrives only almost immediately after the false fast rexmit and maybe it is the only segment unnecessarily rexmitted. However, if segments are delayed such that they arrive at the receiver as the last segments in the current window and there is a relatively large chunk of segments reordered (maybe half of the window) and SACK is in use, the sender unnecessarily rexmits half a window of segments before Eifel detects that the fast rexmit was spurious. And, when Eifel detects it, it does not know what has I think we all agree that the problem of spurious rexmits is important to solve and it should be properly. Therefore, IMO we should handle these in separate documents common to all CCs as we already did for spurious RTOs (which actually needs an update), not in this draft without any evidence presented to the wg for making the decision. |
|
@markkukojo I presented your objections on this topic at the TCPM IETF meeting today (still Nov 11th in PST) and I see two problems that are a bit tricky to solve.
I have not attended all IETF meetings in the past, so I can't say what data may or may not have been presented. But I can say for sure that there are many QUIC implementations (including ours) that are doing UNDO on detection of spurious retransmits and the improvement in throughput was significant for us to keep using it. If you'd like I can get an exact number of how many implementations that are widely deployed are doing this. So, I am starting to lean towards this approach. How about we document how CUBIC should respond to spurious events due to, a. RTOs and We can use RFC 4015's response for a. and we can do the UNDO method for b. (backed by multiple QUIC deployments) |
This sounds good to me. Thanks, Vidhi! @markkukojo said:
As I noted,I'm referring to several different detection mechanisms:
If we're going to stop work based on lying receivers, this is going to hold
I believe we do have such an algorithm, even if it's not documented
I think this passage is missing a key distinction. I think it is (a) How the TCP connection as a whole, and loss detection, and (b) What the congestion control module should do when the logic in (a) I continue to argue that it is useful and best for 8312bis to document |
|
Could we drive this issue to closure, please? |
|
I will send out a PR in a day or two. |
Markku Kojo said,
The text was updated successfully, but these errors were encountered: