Re: Historical question: Link layer flow control / silent discard
[email protected] (Noel Chiappa)
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
> From: Bob Braden <[email protected]> > The following sentence from that document says it all; > "All of our algorithms oscillate, some worse than others." That just means we didn't have a good enough control theorist working with us! :-) (My memory of control theory is very dim now, but I seem to recall that _any_ system with feedback will oscillate unless damped properly... and usually even when damped, there is _some_ oscillation, it's just contolled to the point that it's not harmful, but instead is helpful, as 'probing'.) But seriously, I do think we probably still don't really understand if SQ would work or not. (Although the ECN mechanism explores a somewhat similar space, it depends on the packet getting to the ultimate destination, and then back, successfully, to get the congestion signal back to the originating host). > Sending a packet when there is an overload must be a losing strategy! But the SQ travels over a path which is not (yet) congested... > From: John Day <[email protected]> > I define flow control as feedback co-located with the resource being > controlled and congestion control as feedback not co-located with the > resource That's an interesting - and perhaps useful - distinction, but I fear we are trying to put too many meanings onto too few terms. I still maintain that because of the grubby low-level engineering distinctions (different causes, different mechanisms, etc) it's useful to distinguish between end-end control at the transport layer, and indications of congestion on the path, at the internetwork layer. I guess I was committing the same sin as you, in re-purposing existing terms (flow and congestion control) to the cases I was interested in distinguishing. Maybe instead we need a whole new taxonomy/terminology for this area? Noel