> On 5 Jun 2020, at 17:16, Mark Allman <mallman@xxxxxxxx> wrote: > > >> Mark, that is what I am questioning, > > well ... > >> that by default loss implies congestion. Historically true for >> the IETF but I think that there are a growing number of cases >> where it is not true as in a post I saw on another WG list this >> week where a document was saying that loss MUST NOT be taken as an >> indication of congestion so the MUST in this I-D I find too >> strong. > > OK. So, I am not sure what to do here. I will say several things ... > > (1) I believe that as a general, default the document is quite right > in specifying a congestion response and exponential backoff. > > (2) I believe consensus of the WGs has been the same as my notion in > (1) for some time now. So, even setting aside (1), I am not > sure I feel like I have carte blanche to change this. > > (3) I do not believe loss always means congestion and I do not > believe assuming such is always correct or should always be > done. I don't think I know anyone who thinks that. So, the > document explicitly says that is fine, just go get consensus > that some other approach is fine. (And, that should be > happening regardless of this document, so I am not sure what the > big deal is here.) > > So, basically, I am not sure what to do here. Maybe one of the ADs > can help. Or, maybe we can set this aside and I can do the things I > told you I'd do and a little extra framing will make this better. I > am all ears for advice here. > > (BTW, I have a half response to Stewart, as well. I am not ignoring > his review. I am just behind.) > > allman > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call A good example of congestion free transient loss is a link failure repaired 50ms later by FRR. - Stewart -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
