Verifikation von IP-Multicast | 11. April 2023 | Final

Verifikation der Anwendbarkeit von IP-Multicast am Max-Planck-Institut

Erste Ergebnisse

Steffen Tambach

2Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Agenda

Rückblick – letzter Stand

Aktueller Stand

Weiteres Vorgehen/ Lösung?

Diskussion & Fragen

5 Min.

5 Min.

5 Min.

10 Min.

15 Min.

40 Min.

Messungen an der Senke

3Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Agenda

Rückblick – letzter Stand

Aktueller Stand

Weiteres Vorgehen/ Lösung?

Diskussion & Fragen

Messungen an der Senke

4Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Wdh. Testszenario No. 4 – Paketverlustmessungenam Empfänger

Messwerte (gesendet 1.000.000 Pkts. à 100 Byte)

• Shomiti (1.000.000 Pkts.)

• Receiver 1 (999.980 Pkts.)

• Receiver 2 (1.000.000 Pkts.)

• Receiver 3 (1.000.000 Pkts.)

• Receiver 4 (997.680 Pkts.)

5Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Nachweisbare Verluste auf der Empfängerseite erfordern weitere Testszenarien (Vorschläge aus der letzten Diskussionsrunde):

Verwendung von reinem UDP unicast anstelle von IP-Multicast

Verwendung von TCP anstelle UDP: Werden Datenpakete wiederholt

gesendet?

Künstliche Erzeugung eines burstartigen Verhaltens der Quelle

Quelle ist der Verursacher von Verlusten bei der Senke

Besteht ein Unterschied zwischen C/C++ und Java hinsichtlich der

verwendeten Ressourcen?

Punkt-zu-Punkt-Verbindung mit TAP und Shomiti Explorer

(Simulation der Quelle mittels Paketgenerator des Shomiti Explorer)

Rückblick (Diskussion)

6Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Agenda

Rückblick – letzter Stand

Aktueller Stand

Weiteres Vorgehen/ Lösung?

Diskussion & Fragen

Messungen an der Senke

7Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Empfänger-Testszenario No. 1 zum Suchen der Paketverluste in der Senke

Erweiterung der Testprogramme

• mcReceiverJava (Java-Code)

• mcReceiverC (C/C++-Code BSD Socket-API)

• mcSniffer (Linux paket filter)

• mcModule.ko (Kernel-Modul f. 2.6.x. Benutzt die Hook-Funktionen im Netzwerkstack des Kernels)

8Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

50 Messreihen à 100 Byte payload (Ø 2ms pro Paket)

Stochastisches Auftreten der Paketverluste bei den Empfängern

Ergebnisse

1. Shomiti – Kanal 1 (TAP) alle gesendeten Pakete empfangen

2. Shomiti – Kanal 2 (Switch) alle gesendeten Pakete empfangen

3. mcReceiverJava 0 ~ 3.000 Pakete verloren

4. mcReceiver 0 ~ 1.000 Pakete verloren

5. mcSniffer 0 ~ 900 Pakete verloren

6. mcModule allealle gesendeten Pakete empfangen

Wie werden ankommende Pakete von der NIC bzw. vom Kernel behandelt?

9Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Weg eines Pakets im Linux-Kernel (Auszug)

Quelle: Linux Architektur – Konzepte, Strukturen und Algorithmen von Kernel 2.6

10

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Linux 2.4.x / 2.6.x- Kernel Konfigurationsmöglichkeiten

Kernel-Patch Neukompilierung des Kernels

zur Laufzeit über das /proc- Filesystem (root-Rechte erfordl.)

echo 20971152 > /proc/sys/net/core/rmem_default

echo 1048576 > /proc/sys/net/core/rmem_max

weitere Einstellung zu den jeweiligen Socket-Buffer sind hier ebenfalls

möglich (wmem_default)

Aber eine zusätzliche Kontrolle ist im Programm zur Laufzeit notwendig!

Socket-Konfiguration – WrtBuffer/ RcvBuffer (1/2)

11

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Unter C/C++ (Linux) verwendet die BSD Socket-API standardmäßig die rmem_default bzw. wmem_default Werte. Diese Werte sind kernelabhängig!

int rcvSize =1048576, socket_descriptor =0;

socket_descritor =socket(PF_INET, SOCK_DGRAM, 0);

setsockopt ( socket_descriptor, SOL_SOCKET, SO_RCVBUF, &rcvSize, sizeof(rcvSize) );

Für Java-Anwendungen gilt der Default-Wert (i.d.R. 54KB)

Multicast mc =new MulticastSocket(int port);

mc.setReceiveBufferSize(int size)

Konfiguration der default bzw. max -Werte im Betriebssystem MS Windows 2000/XP ?

Socket-Konfiguration – WrtBuffer/ RcvBuffer (2/2)

12

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

UDP-Verluste auf Empfängerseite sind u.a. ein Bufferproblem

UDP besitzt keine Flusskontrolle, d.h. ist der Socket-Buffer voll,

werden ankommende Pakete verworfen

Aufbau und Speicherstruktur von Netzwerkkomponenten spielen

hier eine wichtige Rolle!

Zusammenfassung

13

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Agenda

Einführung/ Rückblick

Aktueller Stand

Weiteres Vorgehen/ Lösung?

Diskussion & Fragen

Messungen an der Senke

14

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Umsetzung der gewonnenen Erkenntnisse im MonitorClient (MonClient) (1/2)

CPU-Auslastung

Netzwerk-verkehr

15

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Umsetzung der gewonnenen Erkenntnisse im MonitorClient (MonClient) - Erhöhung der Bandbreite (2/2)

16

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

MonitorClient (MonClient) – Architektur

UML-Diagramm MonClient (Auszug)

GUI network

17

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

MonitorClient (MonClient) – Messungen zur Laufzeit (1/2)

Test des Empfangs von Paketen sowie deren Visualisierung mittels der

Open Source Physics Library (vgl. Folie 14/15) durch zwei Referenzzähler

innerhalb der Klassen MonClientWorker und MCAReceiver Ausgabe/

Ergebnis erfolgt durch die addShutdownHook-Methode (Runtime) nach

Beendigung des MonClients

Messergebnisse (Auszug) ~ 5,4MBit/s; 72000 Pkts.; 3 hops

pktCounterModule pktCounterRcv. pktCounterVisualizer72000 72000 2122472000 72000 2460172000 72000 2496072000 72000 19724…

18

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

MonitorClient (MonClient) – Messungen zur Laufzeit (2/2)

Wdh. mit voller Bandbreite (91,21 Mbit/s) führt zum Verwerfen empfangener Pakete bereits auf der Netzwerkkarte – sh. NIC-Statistik

Messergebnisse(Auszug) ~ 91,21 MBit/s; 7.200.000 Pkts.

pktCounterModule pktCounterRcv. pktCounterVisualizer7.081.222 5.563.730 23.2507.200.000 5.560.132 24.220…

eth0 Protokoll:Ethernet Hardware Adresse 00:0A:E4:2E:2A:34 inet Adresse:172.17.10.5 Bcast:172.17.255.255 Maske:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12544657491 errors:118778 dropped:237556 overruns:118778

TX packets:1456 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 …

19

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Agenda

Einführung/ Rückblick

Aktueller Stand

Weiteres Vorgehen/ Lösung?

Diskussion & Fragen

Messungen an der Senke

20

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

UDP besitzt eine unregulierte Senderate (u.a. CPU-abhängig)

Implementierung UDP mit dynamischer Lastanpassung (adaptive

Überlastkontrolle)

Aufbrechen des BooleanLock-Musters (Thread-Synchronisation)

asynchrone I/O, Paketwarteschlange

Weiteres Vorgehen

21

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Danke

Noch Fragen?

22

Verifikation der Anwendbarkeit von IP-Multicast – Erste Zwischenergebnisse

Diskussionsergebnisse / @ToDo

Der Open Source Physics Visualizer besitzt nur eine begrenzte Aufnahme von Daten?

Schnittstelle Netzwerkkommunikation C/C++ Darstellung der Daten mit Java

Konkrete Aussagen über die Konfiguration unter Win2000/ XP Windows Registry

Hennig/Müller Testprogramm Speichergrenze für UDP-Sockets

Nice to have: jfreechart OSP