# Paketverlust bei INFO-Nachrichten führt zu Verzögertem re-discovery von client-IP-Adressen

## Beschreibung des Szenarios Der l3roamd erkennt beim client-roaming auf mac-Ebene den neuen client und versendet ein CLAIM-Paket per unicast an den früheren upstream-node des clients. Dieser antwortet mit einem INFO-Paket. Sofern nach einem Timeout von 1s kein INFO-Paket den neuen node erreicht hat, finden bis zu 3 weitere CLAIMs statt.

Hat das claim den alten node erreicht und ging jedoch das INFO-Paket verloren, hält der alte Node keinen offenen Socket mehr auf der node-client-ip. Die CLAIM-retries laufen damit ins Leere.

## Auswirkung Ein Roaming-Vorgang findet statt, es werden jedoch nicht die routen und IP-Adressen des clients sofort umgezogen. Stattdessen muss für jede IP-Adresse des clients eine (netzweite!) SEEK-Phase stattfinden um die IP-Adressen zu ermitteln. Das kann mehrere Sekunden dauern. In der Zwischenzeit reißen die Verbindungen des Clients ab.

## Lösungsmöglichkeiten ### nichts tun Es ist lediglich ein Client betroffen, wenn Paketverlust beim Roaming auftritt. Der Schaden ist lokal begrenzt.

### ACK einführen Man könnte dem Empfang von INFO-Nachrichten quittieren. Erhält der Info-sendende node kein ACK, verschickt er im retry-Intervall weitere INFO-Nachrichten bis entweder der max-retry-count abgelaufen ist oder ein ACK kommt.

Für kurze Zeit wäre die special-IP dann auf zwei Nodes im Netzwerk zugeteilt. Wie verhält sich babel in der Situation?

Auswirkung auf Roaming bei Paketverlust: die roaming-Geschwindigkeit wäre etwas verlangsamt, die neue node-client-ip und die dazugehörige Route wird erst später übernommen.

### Für jeden Client eine eigene Multicast-Gruppe einführen zu dem sich nodes die Interesse an den Daten haben subscriben. Dann kann eine subscription über den Zeitpunkt hinweg aufrechterhalten werden, an dem ein Client sich von einem Node trennt und retries werden möglich. Dafür bräuchten wir multicast-routing.

### viele Unicast-Adressen dem node zuweisen … - aus einem Pool von 10 Stück und zufällig eine auswählen. Claims an alle 10 möglichen IP-Adressen des clients schicken und die Adressen erst nach eine KArenzzeit droppen.

### eine verteilte Datenbank einführen, die den client-state hält

Hat man eine verteilte Datenbank, kann diese die Informationen bereitstellen. Es gibt mit kadnode eine DHT-Lösung, die ist in voller Ausbaustufe 70KB groß und auf 4MB-Geräten nicht aus dem Stand einsetzbar. Kleinere Varianten sind sicher denkbar.

Was meint ihr?

# Lösung Ich habe ACK implementiert.