[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
detlef.bosau at web.de
Wed Jan 10 15:29:47 PST 2007
Joe Touch wrote:
>> I think of the semantics at the connection level. Which I think to be
>> sufficient in many cases.
> The result is that you think you started/ended a connection correctly,
> but that the wrong data got there?
Well, it´s just how I understand the semantics of a "CLOSE ACK". When a
receiver issues a CLOSE ACK, we know that all data has reached the
receiving socket. What we do not know is whether the data has reached
the application. To my understanding that´s one reason why we use
acknowledgements on application level when it is necessary to know
whether an application has received all data.
So, to my understanding a PEP which keeps the semantics at the
connection level keeps all semantics which is provided by TCP itself.
Acknowledgements at the application level are beyond the scope of TCP.
> As to PEPs...
>> Otherwise the problem is: When the bandwidth sender - splitter is, e.g.,
>> the average bandwidth / rate splitter-sender but far less than the
>> maximum rate splitter / sender than a simple router perhaps would hardly
>> store any data and thus hardly equalize the rate / delivery times.
>> Thierry describes delay spikes of several seconds. If we think about
>> UMTS, we can imagine a wireless link were nothing happens for up to
>> several seconds - thus even no data is clocked out from the sender - and
>> then we have about 2 Mbps throuhput for a short time - which is perhaps
>> much more than the actual Internet path can carry. In such a scenario we
>> want to have the router / splitter / PEP / whateverbox buffer the data
>> and equalize the rate variations. Can this be achieved by pure pacing in
>> the one or other direction?
> Pacing is a simpler version of what you're asking ACK clocking to do; if
> ACK clocking works, pacing definitely should.
The problem I mean is very similar to problems like ACK compression or
the problem descriped in an RFC draft by Craig:
Craig addresses the problem that during slow start bursts may grow that
large that buffer queues on the path may be overloaded.
A similar problem may happen when a mobile network has intermittend
delay spikes and phases with high througput. In phases with high
throughut a mobile might receive a data burst and thus an appropriate
data burst is clocked out at the sender which may overrun queues on the
Craig proposed to overcome this problem by appropriate ACK spacing, i.e.
intendedly puts short time gaps between ACK datagrams.
The problem is also addressed in a paper "Paced TCP for High
Delay-Bandwidth Networks" by Joanna Kulik, Robert Coulter, Dennis
Rockwell and Craig Partridge.
The one interesting question for me (perhaps not for the community,
depending on the answer ;-)) is: Do we already have a pacing / spacing
scheme which provides appropriate ACK spacing for mobile networks?
And of course this question very much depends on whether the problem of
intermittend bursts in mobile networks is relevant. That´s why I wrote
the post on hiccups in mobile networks some days ago. I haved looked for
literature in this area quite intensely but found it extremely hard to
get useful information here. I already refered to the Globecom 04 paper
by Thierry Klein but I did not find really useful additional material on
this issue. Particularly scheduling algorithms seem to be company
confidential quite often so it is extremely hard to get information there.
Moreover, I´m not quite sure whether ACK spacing is already in use here
(sic!) because one consequence of doing ACK spacing in mobile networks
is that the sender is confronted with a large delay bandwidth product.
From the literatur about mobile networks I know that large delay
bandwidth produckts are often claimed for mobile networks - however no
one could explain to me where the claimed path capacity should come
from. It´s surely not the wireless channel which typically hardly keeps
an IP packet layer. I don´t think it´s likely that the ARQ buffers
provide too much memory capacity because a "sliding window scheme" for
ARQ and RLP would require mobile receivers to keep a number of
incomplete IP-packets and therefore a certain amount of storage capacity
for a questionable benefit because in mobile networks the wireless path
can keep only very few RLP frames on the fly.
In short: Perhaps we may find some kbytes memory on L2 here. Perhaps the
layer 2 may keep an average of one or two IP packets. That does
absolutely not explain why mobile networks are frequently claimed to
have that large bandwidth delay products that this would be a problem
So, I´m just eager to know what mobile network operators are doing here.
If mobile networks really exhibit that large delay bandwidth products,
and if we have intermittent bursts and delay spikes here we do not talk
about some kbytes but we talk about up to several hundred kbytes and
more depending on how bursty the traffic is, we have the same issues
here as we have in satellite networks and other networks with an
extremely large delay bandwidth product.
So my question is of course a state of the art question. And I spent a
huge amount of time for literature research on this issue but as I said
its extremely hard to find resilient research papers here. Most of the
information I found is either extremely vague or it is written in PhD
theses which are written in close cooperation with network operators and
where I find claimed problems - but when it comes to details, this is
"corporate confidential", which is definitely not my understanding of
In know that this post here exhibits a very strong criticism against
many papers which present "results" from "practical experiences with
But after having read dozens of papers of this kind for years, my
conclusion is that many of the authors present snapshots of non
repeatable experiments here and do not really know what they have
measured. The more material I read of this kind the less I´m convinced
that the material is good.
So, it´s my personal opinion, and if this is wrong I´m willing to accept
criticism here, that when it comes to mobile networks we have quite a
few statement of belief but hardly any resilient material.
And what I find extremely annoying here is the permanent excuse "we
cannot say anything about the wireless channel". I own a cell phone
myself for more than a decade now and use it frequently. And in fact,
mobile NOs know there channels that well that they can offer phone
service. So the knowledge on mobile channels may be incomplete - but
there is more than nothing. In addition, there is a bunch of work on
adaptive channel coding. Now, you cannot adapt a coding scheme when you
don´t know what channel properties your coding scheme shall be adapted
to. So obviously, there _are_ channel models.
And they are practically used. And there _are_ Radio Link Protocols and
thre _are_ MAC- and scheduling schemes.
But when I ascked even research engineers in well known companies which
build mobile phones why e.g. GPRS accepts delivery times for a packet of
up to 10 minutes, no one was able or willing to explain this to me. Now,
why it´s in the standards, when there is no explanation for this or no
necessity to accept this?
I was involved in an academic research project which dealt with
adaptation of multimedia streams at varying channel conditions in mobile
networks. And even there I didn´t get resilient material at which
conditions I should adapt by our industrial partners. The inevitable
consequence was that the reserach ended up in a pure disaster. I waisted
years of my life on this one. So, when I write this post, you see me in
fact in an angry and bitter condition.
Nearly seven years ago, a professor asked my what are the
characteristics of mobile network. After seven years I still do not know.
And when I tried to talk to colleagues from mobile phone manufacturers
the only remark was: "Oh, I see, you´re used to wirebound networks".
I have seen a number of PhD theses dealing with hiccups. But I have not
yet seen any resilient material whether there _are_ hiccups.
Of course we can do research that way: "Let´s assume hiccups." O.k. But
which assumptions are reasonable here? And which are resulting delay
bandwidth products? 10 kByte? 100 kByte? 10 MByte? And which RTTs are we
going to see if we use sufficient buffering? 1 second? 2 seconds?
Or - according to the ETSI standard for GPRS - a quarter of an hour?
During the last seven years of my life, from which I am unemployed the
last three years, I always wanted to understand only one thing:
"What are the consequences of mobilty and mobile networks for TCP and
And after seven years, to the best of my knowledge, I say: We have a lot
of creeds - but hardly any resilient knowlege.
More information about the end2end-interest