RES 203 Applications Internet dario.rossi Introduction aux applications Dario Rossi http://www.telecom-paristech.fr/~drossi RES203 v2016/12

Plan Terminologie et perimetres de RES203 Application et Protocoles Architectures applicatives vs Architectures reseaux Applicatives: Client-server, Content distribution networks, Peer-to-peer Reseaux: IP Multicast, Content centric networking Couche applicative et couches TCP/IP Interactions Interface (socket) Type d’applications et mesure de performance Applications orientés donnés vs application multimedia (voix, video) Quality of Service (QoS) vs Quality of Experience (QoE) Choix du protocole de transport Emulation Conditions de réseaux, QoS & QoE References 2

Que sont les applications ? User Raisons d'être des réseaux informatiques Nombreuses types: accès distant, email, transfert de fichiers, newsgroups, forums de discussion, Web, multimédia téléphonie, vidéoconférence, audio et vidéo à la demande, etc. Vagues de popularité: Mode texte (1980s) Web (1990s) P2P (2000s) Social (2010s): Souvent : logiciels distribués entre plusieurs systèmes Communication entre les applications application transport network data link physical Router AS1 AS2 Billing Server Video Server application transport network data link physical application transport network data link physical

Applications: une vue d’ensemble “Application” est un terme abusé ou imprecis L’application de messagerie c’est votre logiciel mail preferé ? On definira plusieurs aspect qui sont commun aux applications Architecture Procole Processus: agents et daemons Communication inter-processus Sockets Architecture Hote Agent utilisateur Socket Protocole Socket Daemon Serveur

Applications réseaux : processus Les entités communicantes sont des processus, soit programme applicatif qui s’exécute sur un hôte Deux processus communiquent sur un même hôte avec des communications interprocessus définies par le système d’exploitation Deux processus s’éxécutant sur deux hôtes différents communiquent en échangeant des messages applicatifs avec un protocole de couche application Ces processus peuvent avoir un role different en fonction de l’architecture Le processus émetteur et récepteur supposent qu'il existe une infrastructure de transport en-dessous RES203 INF RES201

Les protocoles … Bonjour Bonjour T’as du feu ? Les humains utilisent des protocoles sans arrêt… un example avec Alice et Bob Protocoles humains: Emission de messages spécifiques “Quelle heure est-il ?”, “S’il vous plait”, “Veuillez agréer” … Actions spécifiques accomplies après réception de messages ou d'événements particuliers Bonjour Bonjour T’as du feu ? … 6

Protocoles applicatifs Définissent : Le type des messages Requête, réponse… La syntaxe des types de messages : Format des champs du message La sémantique des champs, La signification des champs Les règles de communication Déterminent quand et comment un processus envoie des messages et y répond Protocoles applicatifs du domaine public Définis dans les IETF RFC (ex HTTP, SMTP, client-server) Definis dans autres fora (e.g., Gnutella, BitTorrent BEP, etc.) Propriétaires ex KaZaA, Skype, téléphonie IP, application transport network data link physical application transport network data link physical application transport network data link physical

Architectures applicatives Terminologie Communication logique L4/L7 Service consumer Service producer Infrastructure physique Internet Local/regional nets Servers

Architectures: Client-server Paradigme client-server Problemes de passage à l’echelle

Architectures: Client-server Le côté client d'un système terminal communique avec le côté serveur d'un autre système Le serveur doit servir toutes le requetes de plusieurs clients (problemes de charge) Examples Web : navigateur Web = côté client de HTTP serveur Web = côté serveur de HTTP Email : Serveur émetteur = côté client de SMTP, Serveur récepteur = côté serveur de SMTP. application transport network data link physical application transport network data link physical Les applications Internet typiquement s’appuient sur deux entités: le client et le serveur

Architectures: Client-server Demande un service Initie le contact avec le serveur, ouverture active de la connession Implementé dans un logiciel usager Web browser, mail reader, … Serveur: Propose des services Reste à l’écoute pour des requetes de service Implementé dans un daemon Le serveur Web, SMTP, … Remarque : Les applications client-server peuvent etre centralisés Une même machine peut implémenter les côtés client et serveur au meme temps Client application transport network data link physical Server application transport network data link physical Les applications Internet typiquement s’appuient sur deux entités: le client et le serveur

Architectures: Multicast, CCN … IP Multicast, Content Centric Networking CCN Complexes (IP multicast utilisé pour TV over IP)

Architectures: CDN Content distribution network (CDN) Infrastructure couteuse

Architectures: CDN Examples Content distribution networks Client Business de replication de contenu le plus proche à l’usager But: eviter le cout de transit customer-provider entre AS et ne le payer qu’une seule fois Examples Videos YouTube (pre-google era), patches Microsoft, Antivirus 28 services CDNs commerciaux en 2011, parmi les plus connus Akamai, Limelight, application transport network data link physical CDN application transport network data link physical application transport network data link physical

Architectures: Peer-to-peer Paradigme P2P Couche application (deployment facile) Use toutes les resources (scalable) Ressources en periferie (deplace couts)

Architectures: Peer-to-peer Joue le role de client et server à la fois Client, demande des service à d’autres peers Serveur, fournit des services à d’autres peers Remarques : Les serveurs sont des machines dediés, mises en place par un fournisseur de services L’application client-server peut faire assumption que les serveurs soient toujours disponibles (sauf panne). Les peers sont des machines d’usager, qui ne fournit donc aucune garantie de service Les applications doivent faire assumption que les peers ne soient pas toujours disponibles Les applications peer-2-peer sont fortement distribués peer application transport network data link physical application transport network data link physical 16

Architecture: Peer-to-peer Interaction L7 overlay vs IP underlay Les applications Internet (L7 OSI) posent sur l’infrastructure TCP/IP sous-jacente Paradigme P2P P2P overlay IP underlay

Interaction L7 overlay vs IP underlay Les applications Internet (L7 OSI) posent sur l’infrastructure TCP/IP sous-jacente L7 overlay Interaction L7/L3: applications vs couches TCP/IP IP underlay

Interaction L7 overlay vs IP underlay Control du trafic emis (“network friendly” lorsque competition equitable par rapport à TCP) L7 overlay Problematique type L4, solutions autres que TCP (e.g., Skype, BitTorrent, etc.) IP underlay

Interaction L7 overlay vs IP underlay Routage applicatif du trafic (“network aware” quand le trafic est localisé autant que possiable au sein du ISP) $$ L7 overlay Problematique type L3, solutions autres que IP, RIP, OSPF et BGP IP underlay AS1 AS2

Socket: Interface applicative TCP/IP Socket: Application program interface (API) Porte d'entrée des données du reseau d'un processus applicatif Interface entre la couche application et les couches TCP/IP Le développeur contrôle la partie application des sockets il n'a que peu de contrôle sur la partie transport: choix du protocole et ajustement de quelques paramètres Software Contrôlé par le développeur de l'application process process socket socket Software TCP/IP TCP/IP Contrôlé par l'OS Internet driver driver Hardware Contrôlé par le fabricant NIC NIC NIC = Network interface card

Socket: Interface applicative TCP/IP Sockets: Type de protocole de transport Addresse IP de la machine Addresse TCP du processus (numero de port) Addresses Point de vue human: URL http://www.google.com Point de vue réseau L3: Addresses IP L4: Numero de port Traduction Service d’annuaire pour la translation d’addresses (DNS) Remarque: focus de RES224, details dans la suite Regles pour les numeros de port (/etc/services) Remarque: focus de RES223, rappel dans la suite Remarque Le quintuplet (IPs,Ps,IPd,Pd,proto) est unique dans le reseau drossi@enst.fr http://www.google.com TCP/IP TCP/IP Internet 137.192.164.1:37562 74.125.39.180:80

Adressage: point de vue transport Numéro de port: Entier sur 16bits (=65K), double fonctionalité Multiplexage (numeros ephemères > 32K) Permet de différencier parmi les processus locaux auxquels le message contenu dans le datagramme IP recu doit être transmis Resolution (numeros reservés < 32K) Permet un addressage simple et deterministe au niveau transport Well-known port numbers : RFC 1700, /etc/services E.g., 80 pour le serveur Web, 53 pour le DNS, etc. Remarques Un nouveau numéro de port est affecté à chaque nouvelle application par IANA (affectation generalement suivie) Un serveur Web peut tourner sur un autre port (eg 8080) , une appli P2P peut tourner sur un port arbitraire (eg 80, 53) Les applicatif P2P n’utilisent pas/plus de numero de port standard (e.g., pour se cacher) Un client telecharge deux fichiers en parallel à partir du meme serveur HTTP: il ne voudrait pas que les paquets se melangent au niveau TCP ! Une fois resolu l’adresse IP d’un serveur Web, on connait déjà le port du service HTTP (on evite ainsi la 2eme resolution)

Processus: Agents et Daemons Agent utilisateur Implemente le coté client d’un ou plusieurs protocoles applicatif Implémentation du côté client du protocole HTTP: processus qui envoie et reçoit les messages HTTP via un socket Implementation de l’interface avec l’usager (visualisation + navigation + plugins + etc. ) qui depasse le cadre protocolaire et de RES224 Effectue l’open active de la connession TCP (cfr RES223) Utilise (obbligatoirement) un port ephemere Exemples: DNS Nslookup, dig Web Browsers: Mozilla, Chrome, IE Crawlers: wget, … Rapatrie un site Web, ou partie d’un site, effectue un mirror, … Daemon Implemente le coté serveur d’un protocole applicatif Reste à l’ecoute des requetes en provenance des agents utilisateurs (open passive) Utilise (generalement) un port reservé Exemples DNS Berkeley Internet Name Domain (BIND) Web Apache, Microsoft Internet Information Server, Squid (proxy)

RES 203 Applications Internet dario.rossi Introduction aux applications Dario Rossi http://www.telecom-paristech.fr/~drossi RES203 v2016/12

Plan Terminologie et perimetres de RES203 Application et Protocoles Architectures applicatives vs Architectures reseaux Applicatives: Client-server, Content distribution networks, Peer-to-peer Reseaux: IP Multicast, Content centric networking Couche applicative et couches TCP/IP Interface (socket) Interaction applications/transport Type d’applications et mesure de performance Applications orientés donnés vs application multimedia (voix, video) Quality of Service (QoS) vs Quality of Experience (QoE) Choix du protocole de transport Emulation Conditions de réseaux, QoS & QoE References 26

Socket: Quel protocol de transport ? TCP et UDP fournissent des service très different Beaucoup de protocoles de transport existent TCP: Transport Control Protocols UDP: User Datagram Protocol RSVP: Resource reSerVation Protocol SCTP: Stream Control Transport Protocol DCCP: Datagram Congestion Control Protocol T/TCP: Transaction TCP RUDP: Reliable UDP etc. application transport network data link physical

Socket: Quel protocol de transport ? TCP et UDP fournissent des service très different Parfois, ces protocoles sont en realité une famille TCP: Transport Control Protocols UDP: User Datagram Protocol RSVP: Resource reSerVation Protocol SCTP: Stream Control Transport Protocol DCCP: Datagram Congestion Control Protocol T/TCP: Transaction TCP RUDP: Reliable UDP etc. application transport network data link physical Tahoe 1983~ Reno 1983~ NewReno 1999 [IETF default] Vegas 1999 Cubic 2008 [Linux default, 90% servers] Compound 2005 [Windows default, 90% clients] BBR 2016 [Google soon-to-be-default]

Socket: Quel protocol de transport ? TCP et UDP fournissent des service très different Lequel choisir ? Étude des services fournis par chaque protocole Etude du type de contenu de l’application Sélection du protocole qui correspond le mieux aux besoins de l'application Parfois, ces protocoles sont en realité une famille TCP: Transport Control Protocols UDP: User Datagram Protocol RSVP: Resource reSerVation Protocol SCTP: Stream Control Transport Protocol DCCP: Datagram Congestion Control Protocol T/TCP: Transaction TCP RUDP: Reliable UDP etc. application transport network data link physical

Socket: Quel protocol de transport ? Types de flux liés au type de contenu Data Wb e-mail telechargement ... Multimedia Video (on demand, broadcast) Telephone … avec different requis pour leur transport! Taille des paquets (Bytes) Flux HTTP Taille determinée par TCP: train de paquets taille MSS, suivi par ACK Flux Skype Taille determinée par l’encodeur de la voix (à bitrate variable) Numero de paquet

Socket: Quel protocol de transport ? Types de flux liés au type de contenu Data Wb e-mail telechargement ... Multimedia Video (on demand, broadcast) Telephone … avec different requis pour leur transport! Temps d’interarrivée (sec) Flux HTTP Temps determiné par RTT (~20ms) entre 2 trains, pacquets back-to-back (~0ms) pendant un train Temps determiné par l’encodeur de la voix (à bitrate variable) Flux Skype Numero de paquet

Socket: Quel protocol de transport ? Qualité de Service (QoS) (network-centric) Qualité d’Experience (QoE) (user-centric) Bande passante (Throughput) Bits ecoulés par unité de temps Probabilité de perte (Loss rate) Probabilité qu’un packet arrive avec des erreurs detectables mais pas corrigeables (wireless) Probabilité qu’un packet soit perdu à une file d’attente (wired) Delai (Delay) Temps avant que le pacquet arrive Gigue (Jitter) Variabilité du delai Orienté données Temps de completement (Completion time) Reactivité pour applications interactives Fiabilité … Multimedia Peak Signal to Noise Ratio (PSNR) Mean Opinion Score (MOS) Structural similiarity (SSIM) Percetpual Evaluation of Video Quality (PEVQ) Faciles à mesurer, objectifs, peu parlant vis à vis des applications Compliqués, couteuses, pas d’entente à niveau mondiale

Rappel: delai Les paquet subissent du delai à chaque saut Quatre sources de delai: Processement (<ms) - Transmission = P/C (ms – ms) File d’attente (ms – s) - Propagation = D/V (LAN < ms, WAN >10ms) Variable à chaque paquet Fixe pour chaque paquet d’un meme flux Processement Transmission P=taille de paquet C=capacité du lien D=distance V=vitesse du signal File d’attente Propagation

Délai de file d’attente (au goulot d’etranglement) aka “bottleneck” Rappel: delai Les paquets accumulent du delai end-to-end AS1 AS2 … ASn )) (( Eth WiFi … ADSL Débit utile Capacité Délai de propagation (à chaque saut) Délai de file d’attente (au goulot d’etranglement) aka “bottleneck”

Dependence: delai, débit, pertes C: capacité B: taille buffer Point opérationnel souhaitable C Débit utile TCP C Débit en emission Délai (file d’attente) B Débit en emission Pertes Débit en emission Note: la dependence n’est linéaire que pour des fins d’illustration

Dependence: delai, débit, pertes C: capacité B: taille buffer Point opérationnel souhaitable C Débit utile Loss based TCP C Débit en emission Cubic, NewReno Délai (file d’attente) B LEDBAT 100ms Vegas BBR Débit en emission Delay based Pertes Débit en emission Note: la dependence n’est linéaire que pour des fins d’illustration

Délai: Perception humaine Séparation par échelles de temps Reponse logarithmique Action istantané Perceptiblemais sous controle Maintien d’attention Impatience, perte d’engagement Humain* 1ms 10ms 100ms 1s 10s 1m TCP (RTT typiques) TCP (RTT bufferbloat) Load balance (par paquet) Load balance (par flux) Routage * Miller 1968, Nielsen 1993

Flux orientés données Examples Besoin primaire: fiabilité Web, telechargement, sessions interactives, e-mail Besoin primaire: fiabilité L’information doit etre transmise sans erreur, En cas d’erreur, il faut retransmettre L’information doit arriver dans le meme ordre! Utilisent la bande passante disponible (applications élastiques) Autres characteristiques: Pas de contrainte real-time Un delai <3 second pour le debut de l’affichage limite typique pour un service de type Web Edition de texte à distance bcp plus interactif (terminaux, Google documents) Telechargement un fichier peut etre long …mais il devrait etre le plus court possible Retransmissions => limit the size of the data units transmitted in concordance to the probability of loss

Flux voix Pulse Code Modulation (PCM) Transmission numerique Echantillonage, quantification, codage avant de transmettre Besoin primaire eviter délai long et/ou très variable Signal lent, assez robuste aux pertes Amelioration possibles Suppression de silences (ou description de silences pour reduire silence innaturel) Encodage de differences (pour reduire bits de quantification) Compression “lossy“ (suppression des frequences moins importantes) Pulse Code Modulation (PCM) Echantillonage du signal sur un spectre de 4 kHz (après Nyquist 8000 samples per second ) Quantification à 256 niveaux (8 bits par echantillon) Flux de 1 byte chaque 125 µs (64 kbit/s de bande passante) 01001100 11001111

Flux voix Type de flux Characteristiques Pas besoin d’une bande passante importante PCM : 64 kbit/s ; iLBC (Skype) : 13,3 kbit/s ; GSM : 13,3 kbit/s Petit taille de paquet (80 bits to 1 kbit) Temps entre paquet egalement petit (<100 ms) Characteristiques Besoin de limiter le delai end-to-end Pas possible d’utilizer des techniques de “buffering” Maximum “mouth-to-ear” delai tolerable: 300 ms (45 ms si il n’y a pas de suppression d’echo) Robuste contre les pertes qualité plus que acceptable avec 15% de perte Moins robuste si on utilise de la compression (il n’y a plus de information redundante)

Flux video Contraintes similaires à la voix, mais debit important TV : 720 x 576 pixels 16 bits de profondeur de couleur 25 images par second 166 Mb/s flow si pas comprimé La compression est donc très importante MPEG1: qualité VCD 1-2 Mbps MPEG2: qualité DVD 5-10 Mbps Evolutions recentes des dispositifs 4K, HDR, 3D, 100+Hz, ... ne font que rendre la compression de plus en plus importante Idée: exploiter redondances spatiales et temporelles Codage MPEG I-frames: “Intracoded” figure complete JPEG (~1/sec) P-frames: “predictive”, delta par rapport à la precedente B-frames: “bidirectional”, differences de la precedente et de la suivante (!) D-frames: “DC coded”, utilisé en “fast-forward” (~1/sec) I B P

Flux de streaming Example: Besoin primaire: coherence temporelle Contenu multimedia Audio (radio) or video (television) generé en real-time Besoin primaire: coherence temporelle Ni accelerer ni decelerer! Maintenir la bande passante constante Remarque: Estimer ou connaitre le delai du reseau (end-to-end delay) Introduir un delai avant de commencer la vision (playout buffer) Packet sequence number Source Deadline Receiver Frozen stream Delay Time Playout buffer

D’autres types de flux existent Online gaming Très sensible au delai (quelques centaines de ms, end-to-end) Debit typiquement peu important Flux multimedia Transportent different types de flux (video, voix en plusieurs langues, sous-titres, ...) Necessite aussi de gerer la synchronization Jam-session distribuée Playback temps réel (50ms maximum, <20 preferablement) Debit potentiellement bas (MIDI) our elevé (6 Mbps sequencing @192 kHz, 32bit) Example applications: Musigy, eJamming, Autres flux Pas associé à un service specifique Toutes les applications dependent de leur fonctionnement! Flux de controle du reseau Information de controle, routing, etc. Operation and management, verification des liens, … Services applicatif mais “transparents” Translation de noms DNS Signalization et notification d’appel Mise en place de securité

Applications, QoS et transport Transfert de fichiers e-mail Web Audio/vidéo Temps réel Audio/vidéo enregistré Jeux interactifs Messagerie instantanée Pertes Sans pertes tolérant Bande passante élastique audio: 5Kb - 1Mb vidéo:10Kb - 5Mb idem Quelques Kbps Sensible au delai Non Oui, <100’s ms Oui, quelques s Oui, 100’s ms Oui et non Application e-mail Accès distant Web Transfert de fichiers streaming multimedia Téléphonie sur IP Protocole transport TCP TCP ou UDP En général UDP Protocole applicatif SMTP [RFC 821] telnet [RFC 854] HTTP [RFC 2068] FTP [RFC 959] Propriétaire (RealPlayer) Propriétaire (Skype) Mais TCP est de plus en plus utilisé pour contourner les limitations de securité (e.g., firewalls) mises en place

En pratique Service Protocole Transport Remarque Addressage DNS orienté donnés, UDP rapidité avant fiabilité eMail SMTP/POP+IMAP TCP - Acces aux donnés HTTP, FTP TCP interaction L7/L4 Acces aux donnés QUIC UDP éviter `` VoD YouTube bang-bang over TCP interaction L7/L4 P2P * souvent les deux - P2P VoIP Skype UDP, TCP si necessaire controle L7 P2P BitTorrent BitTorrent UDP depuis 2010 eviter impacte sur Skype, etc.

En pratique Aujourd’hui Aujourd’hui LAN Internet Emulation loopback Qualité de Service (QoS) (network-centric) Qualité d’Experience (QoE) (user-centric) Aujourd’hui Emulation loopback TCP / multimedia Aujourd’hui Vous évaluez le MOS pour le multimedia! LAN App Network emulator Internet App App App Loopback + Host only networking Network emulation Faciles à mesurer, objectifs, peu parlant vis à vis des applications Compliqués, couteuses, pas d’entente à niveau mondiale

En pratique Aujourd’hui TP Aujourd’hui TP Emulation loopback Qualité de Service (QoS) (network-centric) Qualité d’Experience (QoE) (user-centric) Aujourd’hui Emulation loopback QoS TCP / multimedia TP Emulation pour HTTP Aujourd’hui Vous évaluez le MOS pour le multimedia! TP Vous évaluez le MOS HTTP! Faciles à mesurer, objectifs, peu parlant vis à vis des applications Compliqués, couteuses, pas d’entente à niveau mondiale

?? || // 48