RTCWeb Evolution
Final Report Abstract
Die Nutzung des Internets für integrierte Audio‐ und Videokommunikation verbreitet sich immer mehr. Derzeit gibt es eine Vielzahl proprietärer Lösungen großer Internetkonzerne welche diese Dienste anbieten. Diese Lösungen sind allerdings nicht interoperabel und erfordern die Nutzung von proprietärer Software oder von Browser Plugins. Um diese Einschränkungen zu überwinden, wurde bei der Internet Engineering Task Force (IETF) die Arbeitsgruppe "Web Real‐Time Communications in Web Browsers" (RTCWeb) und bei dem World Wide Web Consortium (W3C) die Arbeitsgruppe Web Real‐Time Communication (WebRTC) gegründet. Ziel dieser Arbeitsgruppen ist die Entwicklung eines gemeinsamen Standards für Echtzeitkommunikation im Webbrowser. Hierbei übernimmt die IETF die Standardisierung der Kommunikationsprotokolle, wohingegen die entsprechende Programmierschnittstelle (Javascript API) von der W3C Arbeitsgruppe behandelt wird. Der von der IETF standardisierte Protokollstapel muss hierbei eine umfangreiche Funktionalität bereitstellen. Es muss möglich sein, eine sichere Kommunikation über NAT‐Grenzen (Network Address Translation) hinweg aufzubauen, die sowohl Medien‐ als auch Nicht‐Medienströme umfasst. Hierfür werden vorhandene, bereits von der IETF standardisierte Protokolle zu einer neuen, komplexen Protokollarchitektur kombiniert. Dadurch ergeben sich allerdings auch neue, bisher wenig verstandene Fragestellungen und Probleme. Dies bezieht sich insbesondere die Kombination der beiden Transportprotokolle Stream Control Transmission (SCTP) und Real‐Time Transport Protocol (RTP) sowie deren Überlastkontrollmechanismen. Von besonderem wissenschaftlichen Interesse für unser Projekt war die Frage, wie die vielfältigen Medien‐ und Nicht‐Medienströme mit ihren unterschiedlichen Anforderungen und Eigenschaften im RTCWeb‐Umfeld so koordiniert und gesteuert werden können, dass sich für den jeweiligen Anwendungsfall ein den Erwartungen des Nutzers angemessenes Verhalten ergibt. Von den zahlreichen Arbeiten zur Dienstgüte im Netz (QoS) und der daraus resultierenden Qualitätswahrnehmung der Nutzer (QoE) unterscheidet sich die vorliegende Problemstellung dadurch, dass die unterschiedlichen Ströme innerhalb einer Anwendung gebündelt sind. Somit ist prinzipiell die Möglichkeit gegeben, die verwendeten Mechanismen – insbesondere die Überlastkontrolle – aktiv und zielgerichtet zu koordinieren. Frühere Arbeiten haben gezeigt, dass die Verwendung von alternativen, bereits bestehenden Überlastkontrollmechanismen im Kontext von RTCWeb nicht ausreichend ist, um eine akzeptable Dienstgüte zu erzielen. Insbesondere zu hohe Ende‐zu‐Ende‐Verzögerungen sind für Echtzeitkommunikation problematisch. Deshalb fokussierte sich ein Großteil unserer Forschungstätigkeit auf die Reduktion von Verzögerungen im RTCWeb‐Protokollstapel. Dies bezieht sich sowohl auf Verzögerungen ausgelöst durch volle Pufferspeicher in Netzwerkroutern (Queueing Delay), als auch auf algorithmische Ineffizienzen im RTCWeb‐Protokollstapel selbst. Im Rahmen des hier beschriebenen Forschungsprojektes haben wir mehrere Verbesserungen des SCTP‐Transportprotokolls durchgeführt, welche allesamt zu einer Reduktion der Ende‐zu‐Ende‐Verzögerung von Datenübertragungen führen. Diese Änderungen sind bereits teilweise in relevanten Softwarebibliotheken implementiert und werden damit demnächst in allen wichtigen Webbrowsern Einsatz finden. Exemplarisch sei hier der beschleunigte Verbindungsaufbau genannt. Andere Verbesserungen werden gerade beim entsprechenden Gremium standardisiert und damit auch weltweite Verbreitung finden. Weiterhin haben wir zwei Mechanismen für gekoppelte Überlastkontrollen vorgestellt, welche es ermöglichen, Warteschlangenverzögerungen im WebRTC‐Protokollstapel zu minimieren und trotzdem gleichzeitig hohe Datendurchsatzraten erreichen. Einer der Mechanismen ermöglicht dabei die feingranulare Vergabe von Bandbreitenprioritäten unabhängig vom verwendeten Transportprotokoll und von der Anzahl der verwendeten Datenströme. Eine Untersuchung des neuen BBR‐Überlastkontrollmechanismus hat außerdem gezeigt, dass dieser in der ersten Version nicht für einen Einsatz im WebRTC‐Kontext geeignet ist.
Publications
- Integration of RTMFP in the OMNeT++ Simulation Environment. In: Proc. of the 2nd OMNeT++ Community Summit, IBM Research ‐ Zurich, Switzerland, September 3‐4, 2015
Weinrank, Felix; Tüxen, Michael; Rathgeb, Erwin P.
- SCTP User Message Interleaving Integration and Validation. In: Proc. of the 3rd OMNeT++ Community Summit, Brno University of Technology ‐ Czech Republic ‐ September 15‐16, 2016
Weinrank, Felix; Rüngeler, Irene; Tüxen, Michael; Rathgeb, Erwin P.
- ROSIEE: Reduction of self inflicted queuing delay in WebRTC. In: 2017 29th International Teletraffic Congress (ITC 29). IEEE, 2017. S. 7‐12
Flohr, Julius; Rathgeb, Erwin P.
(See online at https://doi.org/10.23919/ITC.2017.8065803) - WebRTC Data Channels. IEEE Communications Standards Magazine, 2017, 1. Jg., Nr. 2, S. 28‐35
Weinrank, Felix; Becke, Martin; Flohr, Julius; Rathgeb, Erwin P.; Rüngeler, Irene; Tüxen, Michael
(See online at https://doi.org/10.1109/MCOMSTD.2017.1700007) - FSE‐NG for managing real time media flows and SCTP data channel in WebRTC. In: 2018 IEEE 43rd Conference on Local Computer Networks (LCN). IEEE, 2018. S. 315‐318
Flohr, Julius; Volodina, Ekaterina; Rathgeb, Erwin P.
(See online at https://doi.org/10.1109/LCN.2018.8638084) - Alternative Handshake Mechanism for the Stream Control Transmission Protocol. In: 2018 IFIP Networking Conference (IFIP Networking) and Workshops. IEEE, 2019. S. 442‐450
Weinrank, Felix; Rüngeler, Irene; Tüxen, Michael; Rathgeb, Erwin P.
(See online at https://doi.org/10.23919/IFIPNetworking.2018.8696905)
