diff --git a/Writerside/images/image_959.png b/Writerside/images/image_959.png
new file mode 100644
index 0000000..798e55b
Binary files /dev/null and b/Writerside/images/image_959.png differ
diff --git a/Writerside/images/image_960.png b/Writerside/images/image_960.png
new file mode 100644
index 0000000..2b66195
Binary files /dev/null and b/Writerside/images/image_960.png differ
diff --git a/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md b/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md
index 4f8f07a..40fbe75 100644
--- a/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md
+++ b/Writerside/topics/04/Rechnernetze/Teil-2/13_TCP-Ende-zuEnde.md
@@ -129,32 +129,6 @@
   - Timeout (RTO)
 - Sequenznummern
 
-## TCP Flusskontrolle
-### Senden
-- TCP-Sender sendet Daten, solange der Sendepuffer nicht voll ist
-  - enthält die gesendeten, aber noch nicht bestätigten Daten
-- ![image_878.png](image_878.png)
-- Sendefenster wird dazu benutzt, um die Anzahl von Bytes anzugeben, die der Empfänger bereit ist anzunehmen
-  - bildet absolute obere Grenze, die vom Sender nicht überschritten werden darf
-
-### Empfangen
-- TCP-Empfänger sendet ACKs, solange der Empfangspuffer nicht voll ist
-- ![image_879.png](image_879.png)
-
-- Empfangsfenster ist dynamisch
-  - wird vom Empfänger in jedem ACK aktualisiert
-  - gibt an, wie viele Bytes der Empfänger noch aufnehmen kann
-
-### Flusskontrolle Beispiel
-![image_880.png](image_880.png)
-
-
-### Datenfluss: Fehlerfreie Übertragung
-![image_883.png](image_883.png)
-
-### Datenfluss: Fehlerhafte Übertragung
-![image_884.png](image_884.png)
-
 ## TCP Pipelining, Sliding Window
 ### Pipelining
 - TCP-Sender kann mehrere Segmente senden, ohne auf die Bestätigung des Empfängers zu warten
@@ -355,15 +329,86 @@
     - → sofortiges Senden kleiner Pakete
   - Delayed ACKs abschalten/reduzieren
 
-## TCP Flusskontrolle und MSS
+## TCP Flusskontrolle
+### Senden
+- TCP-Sender sendet Daten, solange der Sendepuffer nicht voll ist
+  - enthält die gesendeten, aber noch nicht bestätigten Daten
+- ![image_878.png](image_878.png)
+- Sendefenster wird dazu benutzt, um die Anzahl von Bytes anzugeben, die der Empfänger bereit ist anzunehmen
+  - bildet absolute obere Grenze, die vom Sender nicht überschritten werden darf
 
-## TCP Sliding Window
-- rwnd, cwnd, swnd = min(cwnd, rwnd)
+### Empfangen
+- TCP-Empfänger sendet ACKs, solange der Empfangspuffer nicht voll ist
+- ![image_879.png](image_879.png)
+
+- Empfangsfenster ist dynamisch
+  - wird vom Empfänger in jedem ACK aktualisiert
+    - **rwnd = rcvBuffer - (LastByteRcvd - LastByteRead)**
+  - gibt an, wie viele Bytes der Empfänger noch aufnehmen kann
+    - wenn rwnd = 0, warten auf WindowUpdate und keine Daten mehr senden
+
+### Flusskontrolle Beispiel
+![image_880.png](image_880.png)
+
+
+### Datenfluss: Fehlerfreie Übertragung
+![image_883.png](image_883.png)
+
+### Datenfluss: Fehlerhafte Übertragung
+![image_884.png](image_884.png)
 
-## Slow Start (sstresh) und Congestion Avoidance
 
 ## TCP Timeout und RTO-Berechnung
+- nach jeder RTT Messung, um zuverlässig aber nicht zu früh neu zu senden
+
+1. Startwert: RTO = 1 Sekunde
+2. Initialisierung nach erster RTT Messung
+   - SRTT (Smoothed RTT) = RTT_neu
+   - RTTVAR (RTT Varianz) = RTT_neu / 2
+   - RTO = SRTT + max(G, 4 x RTTVAR
+3. Aktualisierung
+   - SRTT = (1- 1/8) x SRTT + (1/8) x RTT_neu
+   - RTTVAR = (1- 1/4) x RTTVAR + (1/4) x |SRTT - RTT_neu|
+   - RTO = SRTT + max(G, 4 x RTTVAR)
+4. Sicherheitsmechanismen
+   - RTO ≥ 1 Sekunde
+   - Exponentielles Backoff
+     - RTO = 2x vorheriges RTO
+     - RTT wird nur für Original-Segmente gemessen
+       - _nicht bei Retransmissions_
+
 
 ## TCP Fast Retransmit und Fast Recovery
+### Fast Retransmit
+- Ziel: Frühzeitige Erkennung von Paketverlusten
+  - Schnelle Wiederherstellung Übertragung
+  - Reduktion unnötiger Timeouts
+- Ablauf
+  - Segment geht verloren, nachfolgende kommen an
+  - Empfänger bestätigt nur letztes empfangenes Byte
+    - Duplicate ACKs
+  - Sobald Sender 3 DupACKs für gleiches Segment empfängt → Verlust
+  - Segment direkt neu senden (KEIN RTO)
+> 3x gemeldet → sofort gesendet!
 
-## TCP Tahoe und TCP Reno
\ No newline at end of file
+![image_959.png](image_959.png)
+
+### Fast Recovery
+- Greift direkt nach Fast Retransmit
+- Ziel: TCP soll nicht in Slow-Start-Phase zurückfallen
+- Sender reduziert cwnd nur moderat
+
+## TCP Tahoe
+- Implementierung von Staukontrolle
+  - SlowStart, Congestion Avoidance, Fast Retransmit
+
+> TCP Tahoe startet neu mit dem SlowStart bei jedem Verlust - Sicherheit geht vor Geschwindigkeit
+
+
+## TCP Reno
+- Weiterentwicklung von TCP Tahoe
+  - Fast Retransmit UND Fast Recovery
+
+> TCP Reno erkennt Verluste früh, sendet schnell neu und erholt sich klug
+
+![image_960.png](image_960.png)
\ No newline at end of file