[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