28. November 2012 12:49

Re: Einige Anmerkungen für Non-Trolls

> > - TCP kann nicht unterscheiden, ob ein Paket wegen einem
> > Übertragungsfehler, wie sie bei Mobilnetzen wegen Schwankungen der
> > Feldstärke üblich sind, verloren geht, oder wegen einer Netzüberlast.

> Eben. Deswegen ist es Blödsinn, sowas auf TCP-Ebene statt direkt auf
> dem Funklink zu bearbeiten.

Ich gebe Dir teilweise recht: In einer optimalen Welt würde man das
Problem auf dem Link Layer, also zwischen Basisstation und Empfänger
lösen.  Dies ist in der Tat der Fall: GPRS/UMTS hat Error Detection
und Recovery (nennt sich RLC) implementiert. Es verträgt sogar Packet
Losses bis ca. 10% ohne nennenswerte Einbrüche im Durchsatz. Darüber
bricht aber der Durchsatz extrem ein.

Nun hatten die MIT-Boys keinen Einfluss auf die GPRS/UMTS-Standards
und sind das Problem deshalb dort angegangen, worauf sie Einfluss
haben: Den Endpunkten.

> > - Selective ACKs (SACK) sind bei kleineren Packet Losses effektiv,

> ...es gibt nach meiner Erfahrung auf der IP-Ebene keine (oder kaum)
> Packet Losses, sondern nur massive Zustellverspätungen, die ein
> TCP-Stack gerne für Paketverlust hält und schmollt (auf die Timeouts
> wartet). 

Auch hier hast Du recht: Im Normalbetrieb gibt es wenige Packet
Losses, siehe RLC weiter oben. Network Coding soll das Problem bei
hohem Packet Loss lösen.

>Um auf mobilen Links effektiv zu arbeiten, braucht man vor
> allem einen Weg, der anderen Seite zu sagen, wann es wieder sinnvoll
> ist, Daten zu senden, und das zeitnah.


Auch das ist in den UMTS/GPRS-Standards schon implementiert. Funzt
aber auch nur bis zu einem bestimmten Packet Loss gut.

Nochmals als Zusammenfassung: 
-Network Coding ist kein Wundermittel, sondern bringt nur in
bestimmten Fällen etwas, nämlich bei sehr hohem Packet Loss.

- Buchtip: "UMTS Network Planning, Optimization, and Inter-Operation
with GSM"

Anzeige

heise online Themen