[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Detlef Bosau]

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:

http://tools.ietf.org/html/draft-partridge-e2e-ackspacing-00

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

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

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

In know that this post here exhibits a very strong criticism against 
many papers which present "results" from "practical experiences with 
GPRS" etc.
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 
upper layers?"

And after seven years, to the best of my knowledge, I say: We have a lot 
of creeds - but hardly any resilient knowlege.

Detlef
> Joe
>
>