[e2e] Wireless Networks. An Example: GPRS.
detlef.bosau at web.de
Mon Mar 11 15:27:31 PDT 2013
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
>> 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
>> 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?"
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.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest