[e2e] TCP ex Machina

[Detlef Bosau]

Am 09.09.2013 20:20, schrieb Hari Balakrishnan:
> On Sep 9, 2013, at 12:57 PM, Detlef Bosau wrote:
>
>> Am 09.09.2013 18:15, schrieb Hari Balakrishnan:
>>> A RemyCC is described by a set of "match-action" rules mapping an
>>> input signal to an action. Each rule has a signal and an action. The
>>> signal we explored in the paper has three components: <ack_ewma,
>>> send_ewma, and rtt_ratio>, where ack_ewma is the EWMA (low-pass
>>> filter) of the interarrival time between new ACKs, send_ewma is the
>>> EWMA of the TCP sender timestamps (echoed in the received ACKs), and
>>> rtt_ratio is the ratio of the most recent RTT to the smallest seen so
>>> far. 
>> So, my understanding is correct that the only congestion signalling in
>> your algorithm is achieved by
>> - the interarrival time of ACKs,
>> - the RTT
>> - the minimum RTT?
> Yes. But please note that the ACKs also tell us the sender's transmission timings of the corresponding packets (segments, if used in TCP). We tried some others but these worked the best. Explaining why that is trickier, and is a question we are investigating currently.

That's exactly the problem in the whole approach.

It's the "classical" conclusion in the wrong direction, AKA "ratio ex post".

There are quite a few factors which have influence on the aforementioned
statistics, amongst these are:

- network load
- in case of wireless ńetworks: recovery delay, varying throughput, e.g.
in HSDPA the net data rate may change every 2 ms becuase line and
channel coding may change
- user behaviour (honestly spoken: unpredictable)
- software behaviour

an additional problem (and IIRC Nilsson, Martin, Ree pointed to that
problem in 2003) in hetereogeneous networks you will see highly
different time scales, e.g. a cross traffic in the Tier 2 network may
cause a load dependent transport time variation of perhaps 10 ns, while
the clock used in the end nodes has a resolution of say 2 ms.

So, a variation in the observed statistics may be caused by several
reasons - nevertheless they are interpreted as load indicators.

When you think of the loss differentiation problem, there are literally
thousands of papers which observe
- RTT
- RTT variation
- Interpacket delay
- Interpacket delay variation / jitter
- RTT distribution, average, median, skew

which well exhibit load dependent behaviour. And which are used to
determine whether an observed packet loss was due to congestion drop or
due to corruption.

All these approaches are condemned to fail because they share THAT ONE
common weakness: Conclusion in the wrong direction.
When a certain symptom arises, you know (by good luck or divine
inspiration) which one of the 100 possible causes does apply.

So the problem is whether the observed statistics are at least suited to
determine changes in network load - and hence are suited to serve as an
input for a closed loop network congestion control. I spent years of my
life in trying to detect network congestion by delay observation and it
took me a long and painful process to finally understand and to admit
that delay observation statistics are simply not suitable for that purpose.

Now, for the simulations, you mainly optimize a target function in n
variables in a perfectly reproducible scenario.
(In general, and there are few exceptions, neither user behaviour nor
wireless network conditions are reproducible at all. Particularly in
small time scales.)

And of course, you will find minima and maxima here by use of some
optimization algorithm.

However: Your parameters (m,b,r in the set of rules) optimize a
mathematical function. And I don't know whether these optimum will hold,
i.e. stay in place, when a user behaviour or wireless network property
or some other parameter beyond your control will change.

Hence, I'm not completely convinced that this approach actually yields a
congestion control algorithm which can be generalized and works with an
arbitrary scenario - as long as some assumptions will hold.

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   70565 Stuttgart                            Tel.:
+49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de