[FRnOG] Impacte de la latence et perte d’acquittement TCP sur le débit

2011-07-10 Par sujet Vivien GUEANT

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

2011-07-10 Par sujet Rémy Sanchez
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

2011-07-10 Par sujet Stephane Bortzmeyer
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

2011-07-10 Par sujet Thomas Mangin
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

2011-07-10 Par sujet Guillaume Barrot
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