[e2e] Wireless Networks. An Example: GPRS.

[Martin Heusse]

Le 11 mars 2013 à 20:39, Detlef Bosau a écrit :

> Am 11.03.2013 17:12, schrieb Martin Heusse:
>> (Although I would tend to think you might need to read a bit about GPRS and cellular networks,
> 
> Be assured: I read quite some literature. However: Could you please be a bit more concrete?
Sorry for this unnecessary remark. 
> 
>>  I'll stick to a more general remark, replacing your reflections in an end to end perspective. And forgive me if I misunderstood you.)
>> 
>> A sliding window (congestion window, anticipation window) allows a sender to use the links on a multi hop paths in parallel when the network device are store and forward.
> 
> Hang on. Sliding window is used to utilize a channel which is able to keep more than one packet in transit. Particularly on the media.
Not particularly, but rather anywhere. An Ethernet "link" composed of several segments connected by switches "holds" just as many packets. A protocol that would not use a sliding window would use that network badly. Do you agree with this?

>>  So to use a GPRS network properly you need a least 4 packets.
>> UE -> BSC
>> -> SGSN
>> -> GGSN
>> -> gateway to dest network
>> Etc.
> 
> At a first glance, I tend to agree, however from what I read so far about mobile networks, these do not necessarily deal with IP packets internally.
Well, ok, PDP, GTP tunnels etc. They are still store&forward, don't you think?
> 
> Nevertheless, when the technology allows to keep more than one packet in transit and is underutilized otherweise, sliding window makes sense. On the air interface (in GPRS actually perhaps "behind" the GGSN) this (at least to my understanding) not always make sense.
Can't you leave aside the air interface? It goes at the speed of light, and not very far. So it does not store much. But the GPRS network does. Don't you think?

> 
> Generally spoken: I've chosen GPRS because of it's huge latencies. And any example I would take, may turn out to be "bad" because the huge complexity of different technologies and implementation used in wireless networks.
> 
>> And that's one way, the return path also count for what's “inflight".
>> (ok, high speed links don't hurt as much a low speed links beyond the bottleneck, but I hope you get the idea…)
>> 
>> Also: RLC-ack (Is that what you call RLP?) does use ARQ… (Are you happy now? ...)
> 
> This is no matter of happiness. It is a matter of fact and it is part of the time necessary to convey a packet.
No, a packet can perfectly be sent up by the BSC before it's acked to the UE. My point was that there are places where ARQ makes sense (on a link with non negligible losses), and other places where an anticipation window makes sense… Guess where? Dadaaaaa: end to end.

> 
> I mentioned the COMCAR project and I should provide a "QoS architecture" there - which included to describe the "rate" available for a stream.
> 
> Later on, in a conference, the first question was: "Mr. Bosau, how do you no the available rate?"
> 
> Period.
? 

> Latest in that moment, it became clear to me that TelCo guys and CS guys (packet switching guys) simply don't understand each other. They talk at cross purposes. Later on, it became clear to me that packet switching and line switching (used for voice) use different APIs. We talk about the years from 2000 to 2005 here.

CS guy?? For me "CS" means "circuit switched", typically TelCo. You probably meant "PS"? Anyway, there is no CS network in LTE, for instance, so it looks like the TelCo guys are going to have to understand what a router is. But I think most of them did…

M.