[e2e] Wireless Networks. An Example: GPRS.

[Detlef Bosau]

Am 11.03.2013 21:58, schrieb Martin Heusse:
> 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?

I think, it was a bit extreme, when I talked about "stop and wait".

In general, sliding window addresses the work conservation. When this 
can be achieved with one segment, it's o.k. When it is reasonable, as in 
your sketch, to use 4 segments, it is o.k. as well.

In the particular case of TCP, we do not know the best window size in 
advance and employ an estimation scheme. What I have in mind is to split 
up TCP congestion control along the path and so be able to use different 
estimation schemes along the individual segments. And you're correct, as 
others are (I got some PM on this one): window size 1 (segment) may not 
be adequate in any case.

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

Se above. A sliding window may be adequate here.

Even more: What you illustrate is a case where we KNOW an appropriate 
window size for a certain path segment, so why should we make this 
subject to VJCC and it's AIMD scheme? When we have sound knowledge, why 
should we rely upon estimation?
>> 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?

I agree. For terrestrial networks. If we employ geostationary 
satellites, the situation may be different. However, it is the same 
rationale as discussed above.

So, perhaps my argument was too extreme - and therefore wrong.

I was pointed to similar situations in UUCP, however, the discussion 
remains the same: When sliding window is adequate, which window size 
yields the best throughput. And I think we can agree that we have 
situation where the ideal window size is known, while in others we have 
to asses the ideal window size.

However, we should avoid to blast buffers by using unreasonable huge 
window sizes.
>>
>> 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.

Really? And that's the point I don't agree. It's just this strict end to 
end principle what I put in question. VJCC estimates the optimal window e2e.
Why shouldn't we exploit SOUND knowledge of path segments?
>
>> 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.
> ?
>

O.k., perhaps this lead to confusion without further explanation.

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

No, CS is Computer Science. In contrast to Electrical/Electronical 
Engineers or Communication Engineers.

Hopefully this clears the confusion.

Detlef


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