[e2e] TCP ex Machina

[Jon Crowcroft]

the work i was referring to uses the Padhye equation which is not claiming
that TCP is "about equations", but has a multi-regime model of how TCP CC
appears to work (based on code - the difference between C code and
equations is of course a purely academic distinction anyhow).

so taking _actual_ packet traces (lots of them) you can see how many packet
losses and timeouts trigger retransmits, and you can see how the TCP send
windows evolve over time, and correlate these with the distribution of mean
and mean square difference of RTT over large numbers of flows...
this correlation is done by curve/parameter fitting, so you need an
equation with parameters (the padhye one is possibly the best of breed)

and the result was as I said.....

the rest of your response doesn't seem to be about end-to-end research, so
I'll leave that to a more philosophical venue for discussion by people
qualified  to do so (not me)

j.


On Mon, Jul 22, 2013 at 12:48 PM, Detlef Bosau <detlef.bosau at web.de> wrote:

> 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.
>
>