Mikael Abrahamsson <[email protected]> wrote: >> >>> I would greatly appreciate if someone could point me to text explaining >>> this so I can better understand the reasoning behind this wording. >> >> I recommend my slides from IETF-77: >> >> https://www.ietf.org/proceedings/77/slides/iccrg-7.pdf >>... >> Briefly, the Queuing Theory definition is the most useful for >> control-loop purposes: >>" >>" congestion is said to occur if the arrival rate into a system exceeds >>" the service rate of the system at a point in time. >> >> This is what I meant "incipient" congestion to mean. > > Ok, I think I understand the reasoning behind it. Now you and the other > authors need to decide if you want these documents to be read and > understood by people like me for instance, who works at service providers > or other networking professions who are not heavy inty queueing theory but > instead are just trying to get their gear to do the right thing.
Speaking for myself, I would like the document to be easy for network operators to read. But I am not an author, and I certainly can't speak for the authors. > I have studied english from grade 4 to grade 11, and I was best in my > class in english. Alas, that doesn't mean as much as it used to... > I had never even heard the word "incipient" before 2 days ago, Q.E.D. ;^) > and even now I am not sure I understand the full meaning trying to be > conveyed. Alas, you're probably right. :^( The temptation becomes overwhelming, at some point in the RFC-generation process, to use terms that "sound right" without defining them well. I have a history of annoying folks by asking for good definitions at and after this point in the process. But I would like to see a definition of "incipient congestion" -- perhaps something like: " " incipient congestion: the detection of congestion when it is just " starting, perhaps by noticing that the arrival rate exceeds the " forwarding rate. I don't think this is inconsistent with previous usage, but YMMV... > If I for instance read RFC2884 "Performance Evaluation of ECN..." > it has 3 mentions of "incipient congestion" but 95 mentions of > "congestion". Am I to understand that these 3 mentions of "incipient" > means that the congestion that is "incipient" is different from the > mentions of just "congestion" without "incipient" before it? RFC 2884 is water over the hill: we cannot change it. My opinion is that it uses "incipient congestion" to indicate that Random Early Detection signals oncoming congestion before it reaches the point of tail-drop. "Congestion" used alone seems to be a generic term covering a quite-wide range of meanings. Note, please, that RFC 2884 is informational -- which means that only the authors are responsible for defining their terms, and that, unless quite specifically cited, its definitions do not affect the meaning of the terms it uses when they appear in other documents. (That is to say, don't bother looking there for definitions that we should have included in _this_ document.) > Because that subtle difference is completely lost to me and if I were to > guess, completely just deleting the 3 mentions of "incipient" from RFC2884 > wouldn't change the document at all. Am I wrong here? Yes, IMHO, but YMMV. It meant (IMHO) to distinguish congestion signals from RED from tail-drop which went before it. > For instance here: > > "Jacobson [14] proposed gateways to monitor the average queue size to > detect incipient congestion, and to randomly drop packets when congestion > is detected." I don't know the context of what you're quoting here, so I can't respond. >> (NB it _does_ make sense to talk of "incipient congestion" persisting >> for a longer period of time, believe it or not!) > > If a queue has a buffer fill of between 40 and 60 ms worth of packets over > 60 seconds, is this link congested or is it experiencing a prolonged > period of "incipient congestion"? Perhaps yes; perhaps no. Particular AQM algorithms may define this either way. > Is the "incipience" (I don't even know if that is the correct term) Yes, it's a word, meaning what I think you intend. > just when the buffer fill time is increasing (for instance from 45 to > 55 ms) and not when it's decreasing from 55 to 45 ms, That would be my preference: when arrival rate exceeds forwarding rate, it's a bad idea to probe for additional capacity; but when the forwarding rate exceeds the arrival rate, there probably is unused capacity which it's reasonable to probe for. (Note, of course, that I do _not_ claim this is consistent with current TCP congestion-control algorithms, which are optimized for the lack of information which we must live with.) > or is it just "incipient congestion" for the entire duration of the > buffer having a constant non-trivial amount of packets in it? Alas, YMMV. The RED algorithm seems to assume that there is some "incipient congestion" whenever some fraction of the buffer is full. I doubt we can fix that in this document, but I'd sure like to try! -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
