Fragen bzgl. Mobile Transport Layer

[ABD]

Es hat vielleicht nicht konkret etwas mit dem Mobile Transport Layer zu tun, aber mit TCP im Allgemeinen:

1.) Congestion tritt ja IMMER auf, dadurch, dass das cwnd in der congestion avoidance linear erhöhrt wird. Irgendwann ist eben Schluss und es treten Verluste auf. Nehmen wir den OPTIMALEN Fall an, es würden durch eine verschwindend kleine Verzögerung 3 Dup ACKs eintreffen und sofort wieder in die congestion avoindance übergegangen werden. Selbst dadruch würde doch ein "Sägezahnprofil" entstehen, wie es auf Folie 10.18 angedeutet ist.
Wenn mich nun nicht alles täuscht könnte demnach die Netzauslastung bei TCP Traffic bei maximal 3/4 der durch untere Layer technisch möglichen Netzauslastung liegen.
Ist dies wirklich de Fall?

2.) Hat die Selective Retransmission etwas mit TCP Reno zu tun? Schließlich:
TCP New-Reno:
• stay in fast recovery until all packet losses in window are recovered
• can recover 1 packet loss per RTT without causing a timeout

[Matthias Hollick]

hallo abd,

wenn der TCP sender "greedy" ist, d.h. immer daten zum versenden bereit hält, kommt es tatsächlich zu einer sägezahnkurve, wenn man an die grenzen des bottleneck links stößt und dort paketverlust auftritt. je nach TCP variante ergeben sich dann die wirklich erzielbaren datenraten (dazu gibt es dutzende paper die das genauer untersuchen, google z.b. mal nach "injong rhee" udnd "congestion control" und du findest zu einer (von dutzenden) arbeitsgruppe die alle möglichen TCP varianten für "high performance TPC" untersuchen)

was meinst du mit "selective retransmission"? TCP RENO ist nicht gleich TCP SACK. die verschiedenen TCP varianten sind nahezu undurchschaubar (siehe z.b. http://en.wikipedia.org/wiki/TCP_conges ... _algorithm -> kann aber nicht für die genauigkeit des artikels garantieren, dient nur der veranschualichung der vielfalt der varianten), für das verständnis der vorlesung reichen die grundmechanismen und grundprizipien aus. welche variante von TCP was benutzt ist also nicht prüfungsrelevant.

-- matthias hollick