[FRnOG] Impacte de la latence et perte d’acquittement TCP sur le débit
Bonjour, J'ai réalisé de nombreux tests pour comprendre les performances réseau avec de la latence et perte d’acquittement TCP. Je ne parle pas des mauvaises performances liées au système d'exploitation client (Rwin limitée à 64 Ko avec tous les navigateurs sous Windows XP et limitée à 255 Ko sous Windows 7 avec les navigateurs IE, Firefox, Opéra) mais des performances coté serveur. On va prendre un cas simple : un abonné sur le réseau Numericbale (avec la fonction TCP ACK Suppression activée sur le modem DOCSIS qui entraîne une limitation à 222 ACK/sec, soit 92% des acquittements TCP dropés à 90 Mb/s) qui télécharge aux USA (latence de 100ms) = Le débit est limité à 580 Ko/s (testé avec 4 clients : Linux, MacOS X, Windows 7 avec une Rwin de 4 Mo et Windows XP avec une Rwin de 4 Mo) J'ai mis en place un serveur en France qui rajoute 100ms : http://100ms.lafibre.info (la latence supplémentaire est générée avec NetEm) et un autre sans la latence en+ http://0ms.lafibre.info ce qui permet de faire le test en ne modifiant que le paramètre latence. - Avec 100ms de latence en + avec TCP ACK Suppression : wget http://100ms.lafibre.info/10Gb.dat -O /dev/null = débit de 580 Ko/s - Avec 100ms de latence en + sans TCP ACK Suppression : wget http://100ms.lafibre.info/10Gb.dat -O /dev/null = débit plus de 10 Mo/s - Avec 0ms de latence en + (avec ou sans TCP ACK Suppression) : wget http://0ms.lafibre.info/10Gb.dat -O /dev/null = débit plus de 10 Mo/s Les débits sont donc bon si nous avons de la latence sans les pertes d’acquittement ou inversement des pertes d’acquittement sans latence. Avec de la latence et des pertes d’acquittement, le débit s'écroule. Malheureusement il n'est pas possible de désactiver la latence quand on télécharge aux USA ou le TCP ACK Suppression sur les modems Numericable. J'ai testé des serveurs mirror Australiens d'Ubuntu avec 1 Gb/s de BP vers le net : Serveur 1 : wget -O /dev/null http://mirror.aarnet.edu.au/pub/ubuntu/releases/11.04/ubuntu-11.04-desktop-i386.iso Je ping ce serveur en 310ms. Avec une connexion limitée à 222 ACK/sec, je suis limité à 0,2 Mo/s Avec une connexion sans perte d’acquittements, je télécharge à 9,4 Mo/s Serveur 2 : wget -O /dev/null http://ftp.iinet.net.au/pub/ubuntu-releases/11.04/ubuntu-11.04-desktop-i386.iso Je ping ce serveur en 365ms. Avec une connexion limitée à 222 ACK/sec, je télécharge à 6 Mo/s Avec une connexion sans perte d’acquittements, je télécharge à 6 Mo/s il y a donc un paramétrage serveur ou un système d'exploitation différent entre ces deux serveurs. http://100ms.lafibre.info/ et http://0ms.lafibre.info/ sont des Linux 2.6.38 + apache 2.2 avec les paramétrages TCP/IP par défaut. Ma question : quel système d'exploitation ou paramètre linux utiliser pour avoir des bonnes performances avec une latence importante et un drop des acquittements au-delà de 222 ACK/s ? Merci d'avance pour vos retours. Vivien. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Impacte de la latence et perte d’acquittement TCP sur le débit
On Sunday 10 July 2011 19:39:04 Vivien GUEANT wrote: Ma question : quel système d'exploitation ou paramètre linux utiliser pour avoir des bonnes performances avec une latence importante et un drop des acquittements au-delà de 222 ACK/s ? Augmente ta MTU. Ok je sors... Y'a eu un troll du genre sur NANOG, ça commence là http://mailman.nanog.org/pipermail/nanog/2010-November/027515.html à priori. Si ma mémoire est bonne ils font le tour des raisons de chute de débit, MTU ou non, et des éventuelles solutions. My 2 bitcoins, -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
[FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change lorsqu'on se déplace (en IP classique, c'est le cas de l'adresse IP), de *correspondance* (mapping), la fonction qui permet de trouver un localisateur en connaissant l'identificateur, de *correspondant* (CN pour Correspondent Node, la machine avec laquelle l'engin mobile communique), etc. La section 3 expose les principes de base de la gestion de la mobilité. Le CN doit pouvoir, dans l'Internet actuel : * trouver l'adresse IP actuelle du mobile (solutions dites de type 1), * ou bien connaître un identificateur du mobile et pouvoir lui envoyer des données en utilisant cet identificateur (solutions de type 2), nettement plus fréquentes. Un exemple de solution de
Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Three (hutchison 3G - UK) fournit une terminaison L2TP a certains FAI - entre autre nous. La session vous suit donc on peut avoir une IP statique et un block d'IP route lors d'un voyage dans un train sans aucun problème. Adrian Kennard de AAISP a parle de l'implementation du point de vu de l'ISP a UKNOF 19 (mais la video n'est pas - encore ?? - disponible sur le site). Il y a beaucoup de tour de magie car évidement la session PPP n'est pas vraiment du dongle a l'ISP. Alors cette RFC c'est pour quoi au fait :p Thomas On 10 Jul 2011, at 21:40, Stephane Bortzmeyer wrote: Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change lorsqu'on se déplace
Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Tous les opérateurs de téléphonie mobile implémentent de la mobilité via Gtp (3Gpp oblige), d'où les S et Ggsn. Des études pour implémenter mobile ip ont été faites il y à quelques années chez nous, avec comme conclusion qu'on ne déploierait pas mais j'ai pas le détail du pourquoi la, si ce n'est que Gtp étant le standard de facto pour les telcos (3gpp), être le premier (voire le seul) à partir sur mobile ip doit poser des problèmes sur la gestion du roaming. Sur un réseau fixe (adsl, ftth) la question ne s'est jamais posée à ma connaissance (je parle bien de mobilité pas d'ip fixe). Le 10 juil. 2011 22:43, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change