[e2e] Wireless Networks. An Example: GPRS.

[Martin Heusse]

Le 11 mars 2013 à 23:27, Detlef Bosau a écrit :

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

Good, that was my point…
Now, you'll have to admit:
1) no one knows the number of store and forward hops nor the latency in advance so you have to guess (or create some kind of cross-layer mechanism… Good luck with that…) The first hop that your TCP/IP stack sees is the GGSN in the GPRS network, and there are many store and forward nodes between them. 
2) back-pressure congestion control is actually implemented in SS7 networks. (LLSU frames) The consequence of it is that a congestion somewhere creates congestion upstream and that's not good (that happened between Free-mobile and Orange in France not so long ago, as far as I know). 

Actually the fact that the congestion goes back upstream when no proper congestion control is used is a good argument against fountain code: links upstream of the congestion get congested… (Which is why, I guess, fair queueing is mandatory if you're going to change the paradigm…)

Martin