Re: Historical question: Link layer flow control / silent discard
Detlef Bosau <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
Am 24.05.2013 19:48, schrieb Noel Chiappa: > > From: Detlef Bosau <[email protected]> > > First, 'flow control' these days is taken to mean 'end-end' - i.e. the > original source not sending data faster than the ultimate destination can use That's certainly correct for TCP. I've not read that much papers on hop to hop flow control - although I think it could well make sense. > it. This has always been handled at the tranport layer - in the case of TCP, In the case of TCP. > by the TCP window. Rate control based on the ability of the _network_ to > carry traffic (which is what you seem to be asking about below) is now > usually called 'congestion control'. ;-) As you may know, I'm putting a little question mark behind end to end congestion control. > > I don't recall how carefully we differentiated between the two back then, > although I am quite sure we already understood the difference. No doubt here. > > When I read the original catenet work by Cerf, the Catenet employed > > link layer flow control. > > I'm not sure that's quite correct: without checking the documents for myself, > I suspect they would have understood that if the source is connected to > network A (a fast network), and the next hop is network B (a slow network), > the link layer flow control on network B would be no use in slowing down the > host - since it's not connected to network B. > > As I recall, we thought ICMP Source Quench would be the way congestion > control would be propogated back to the host. > And (this is again history ;-)) why was this abandoned? (Does anyone happen to recall the reasons?) -- ------------------------------------------------------------------ Detlef Bosau Galileistraße 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 [email protected] http://www.detlef-bosau.de