[e2e] TCP ex Machina
Detlef Bosau
detlef.bosau at web.de
Mon Jul 22 03:48:29 PDT 2013
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.
More information about the end2end-interest
mailing list