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

[Joe Touch]

Detlef Bosau wrote:
> 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.

We should know that. But when we have intermidiates spoofing ACKs, all
we know is that the two endpoints agree that they have closed. The data
itself is not known.

Case in point - if the intermediary ACKs data and continues to buffer
it, and the window wraps, and then the intermediary goes down, the
endpoints think the data reached the buffer correctly but it really did not.

> What we do not know is whether the data has reached
> the application.

TCP is a reliable transport protocol; it is not a reliable application
protocol. Actions outside of TCP are not ensured by TCP.

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

Agreed, but we do know some other things. As a *receiver*, when we issue
a CLOSE, we keep reading until there is no more data. If we do so, AND
we receive a "no more data", then we *know* all the data has been
received correctly.

I.e., the semantics of who knows what are receiver-driven, not sender.

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

See above; PEPs that spoof ACKs can result in different data streams
being 'correctly' processed without either side knowing so.

Joe

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

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070110/48d916ff/signature-0001.bin