Re: TCP ex Machina
Detlef Bosau <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
Am 22.07.2013 09:04, schrieb Jon Crowcroft: > Richard Clegg at UCL presented a nice study recently where he has being > trying to fit TCP equations to lots if big packet traces...h TCP is not about equations. TCP is about data transport. And ONLY about data transport. Some days ago, I once again read Metcalfe's Quote, networking would be inter process communication. No, and once again no. Communication is always a bilateral thing which requires basic agreements. I, myself, am not a process and when I now and then receive messages about penis enlargement pills and the like, this is neither bilateral not based upon basic agreements, it is simply annoying. Packet switched networking is bringing datagrams from a sender to somewhere, hopefully a receiver. (However, next time when a weird printer box causes a broadcast storm and renders a whole company network useless, I will say: "the printer box does inter process communication".) When Fred Baker points to the amount of data being in flight, he points to our worship of work conservation. (At least in part an outcome of Calvinistic ethics. Idleness is a sin. And punished by god.) (However, work conservation is well reasonable when idleness causes cost and should be avoided to spare these.) The more I think about it, the more I tend to distinguish two perspectives. The packet perspective: A packet wants to travel a network and for this purpose it wants to travel a) in direction of its final goal, b) to a free place in the network. Admittedly, for the purpose of a) a packet relies upon routing tables and the like because a packet has no idea about a network's topology. The global perspective: Some global "God", "Spirit", (Adam Smith would call it "the invisible hand") should mange the routing tables that way, that packets will reach their goal reasonable fast and that individual parts of the network must not become overcrowded. The latter is called congestion control. And the more I think about it, the less I'm convinced that our "amount of data in flight" probing, including any forms of "sophisticated dropping of packets" really follows this goal. An individual always travels to a free place which is as close as possible to its final destination. An individual has no idea whether the so found route is optimal (following some criteria) or even makes sense, it could be a dead end. Consequently, my question is whether congestion control should be primarily a matter of route planing. And not a mixture of self scheduling and a struggle for resources. (Although the local perspective, the packet's perspective, is necessarily a struggle for resources.) Perhaps this question was asked many times ago. However I simply ask it once again.