Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Sylvain,

quel est le temps de réponse que tu obtiens? Et quelle taille de window
as-tu lors des transferts?

Le 15 février 2017 à 23:22, <sbu12...@gmail.com> a écrit :

> 100Mb nous sommes en 2017…… en IDF…
>
>
>
> *De :* Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
> *Envoyé :* mercredi 15 février 2017 17:52
> *À :* frnog@frnog.org; sbu123fr; Louis
> *Cc :* Liste FRnoG
> *Objet :* Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens
> (MPLS) 500Mo mais plutot 5 x 100Mo
>
>
>
> Totalement cohérent alors.
>
> Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a
> écrit :
>
> C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en 
> "mono" 100 et des bananes
>
>  Message d'origine 
> De : Louis <luigi.1...@gmail.com>
> Date : 15/02/2017  17:22  (GMT+01:00)
> À : sbu123fr <sbu12...@gmail.com>
> Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
> <frnog@frnog.org>
> Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 
> x 100Mo
>
> Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
> fiable. Pas de lecture disque
> Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le 
> débit. Avec un transfert multi-session, la tête de lecture/écriture d'un 
> disque classique est obligé de faire en permanence des aller-retours.
> Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
> BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur 
> la chaîne de liaison
>
> ---- Message d'origine ----
> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
> Date : 15/02/2017  16:36  (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>   100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
>
>  Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
>  d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
>  J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
>  "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
>  une session TCP entre 2 liens"
>
>
>
>  Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>
>  Oui mais non,
>
>  Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>  liens de façon parfaitement aléatoire, souvent les équipements balancent le
>  trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>  sur le couple adresse source-destination, cela peut-être Adresse IP source
>  / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>  par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>  exceptions, et sûrement des solutions propriétaires.
>
>  Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>  (exception faite des solutions propriétaires ou solutions non déterministes
>  de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>  100Mbps sur un LAG 5x100Mbps pour un même flux.
>
>  cordialement,
>
>  2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>
>  Après quelques recherche, j'arrive à la conclusion que la limitation du
>  temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>  (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>  de l'OS.
>
>  L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>  les (très) vieux OS, la valeur maxi de window size était 65535 octets
>  parce
>  que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>  1323 est largement utilisée. Elle introduit un paramètre window size
>  scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>  size. Le 

RE: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Arthur Pellissier]

+1 : aujourd'hui il est moins cher de poser une FON 1gbps pour faire du 500Mbps... Sans compter la possibilité d'évolution derrière.


Si tu veux te faire une idée du tarif d'une FON sur ton site envoie moi un mail ;) 


De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> de la part de Ducassou Laurent <laurent.ducas...@spaceshell.fr>
Envoyé : jeudi 16 février 2017 08:47:09
À : frnog@frnog.org
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
 



Vois avec ton fournisseur pour te faire livrer un lien 1Gbit/s shape à

500Mbit/s et non 5 lien 100Mbit/s agrégée...

Ca fait 3 ans que même Orange propose en province des liens 
200/500/1000Mbit alors en IDF...

Là c'est plus à toi de voir avec ton fournisseur que autre chose... 
(optionnellement, en passant de 5 liens à 1, tu risque d'avoir la 
facture qui baisse)


Le 15/02/2017 à 23:22, sbu12...@gmail.com a écrit :
> 100Mb nous sommes en 2017…… en IDF…
>
>   
>
> De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
> Envoyé : mercredi 15 février 2017 17:52
> À : frnog@frnog.org; sbu123fr; Louis
> Cc : Liste FRnoG
> Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
>   
>
> Totalement cohérent alors.
>
> Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a écrit :
>
> C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 100 et des bananes
>
>


 






 











Arthur Pellissier


Ingénieur Commercial -
Sales Engineer

5 Quai Marcel Dassault, 92150 Suresnes, France





  
 
 





 +33 1 85 60 10 35

 +33 6 88 02 14 17 
 apelliss...@waycom.net






 



























This message is confidential. It may also be privileged or
 otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax
 any message containing deadlines as incoming e-mail are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.

 


















 Message d'origine 
> De : Louis <luigi.1...@gmail.com>
> Date : 15/02/2017  17:22  (GMT+01:00)
> À : sbu123fr <sbu12...@gmail.com>
> Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG <frnog@frnog.org>
> Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez fiable. Pas de lecture disque
> Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. Avec un transfert multi-session, la tête de lecture/écriture d'un disque classique est obligé de faire en permanence des aller-retours.
> Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
> BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la chaîne de liaison
>
> -------- Message d'origine ----
> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
> Date : 15/02/2017  16:36  (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>    100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
>   Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
>   d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
>   J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
>   "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>   500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
>   une session TCP entre 2 liens"
>
>
>
>   Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>   Oui mais non,
>
>   Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>   liens de façon parfaitement aléatoire

Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou Laurent]

Vois avec ton fournisseur pour te faire livrer un lien 1Gbit/s shape à 
500Mbit/s et non 5 lien 100Mbit/s agrégée...


Ca fait 3 ans que même Orange propose en province des liens 
200/500/1000Mbit alors en IDF...


Là c'est plus à toi de voir avec ton fournisseur que autre chose... 
(optionnellement, en passant de 5 liens à 1, tu risque d'avoir la 
facture qui baisse)



Le 15/02/2017 à 23:22, sbu12...@gmail.com a écrit :

100Mb nous sommes en 2017…… en IDF…

  


De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
Envoyé : mercredi 15 février 2017 17:52
À : frnog@frnog.org; sbu123fr; Louis
Cc : Liste FRnoG
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo 
mais plutot 5 x 100Mo

  


Totalement cohérent alors.

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a écrit :

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes

 Message d'origine 
De : Louis <luigi.1...@gmail.com>
Date : 15/02/2017  17:22  (GMT+01:00)
À : sbu123fr <sbu12...@gmail.com>
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org>
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison

 Message d'origine 
De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
Date : 15/02/2017  16:36  (GMT+01:00)
À : frnog@frnog.org
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
   100Mo

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
client final crois disposer de 500Mbit/s entre chaque site, mais en
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
  Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
  d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

  J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

  "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
  une session TCP entre 2 liens"



  Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
  Oui mais non,

  Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
  liens de façon parfaitement aléatoire, souvent les équipements balancent le
  trafic de manière *déterministe* sur l'un des liens physiques, en se basant
  sur le couple adresse source-destination, cela peut-être Adresse IP source
  / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
  par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
  exceptions, et sûrement des solutions propriétaires.

  Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
  (exception faite des solutions propriétaires ou solutions non déterministes
  de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
  100Mbps sur un LAG 5x100Mbps pour un même flux.

  cordialement,

  2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
  Après quelques recherche, j'arrive à la conclusion que la limitation du
  temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
  (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
  de l'OS.

  L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
  les (très) vieux OS, la valeur maxi de window size était 65535 octets
  parce
  que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
  1323 est largement utilisée. Elle introduit un paramètre window size
  scaling factor (8 bits) qui est un multiplcateur de la valeur de window
  size. Le window size est étendu 16Mo au lieu de 64Ko.

  Calculateur de bande passante sur une session TCP :
  https://www.switch.ch/network/tools/tcp_throughput/
  Pour la formule, c'est ici :
  http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-t

RE: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

100Mb nous sommes en 2017…… en IDF…

 

De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr] 
Envoyé : mercredi 15 février 2017 17:52
À : frnog@frnog.org; sbu123fr; Louis
Cc : Liste FRnoG
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo 
mais plutot 5 x 100Mo

 

Totalement cohérent alors. 

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a écrit :

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes 

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> 
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
 Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
 d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

 J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

 "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
 une session TCP entre 2 liens"



 Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
 Oui mais non,

 Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
 liens de façon parfaitement aléatoire, souvent les équipements balancent le
 trafic de manière *déterministe* sur l'un des liens physiques, en se basant
 sur le couple adresse source-destination, cela peut-être Adresse IP source
 / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
 par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
 exceptions, et sûrement des solutions propriétaires.

 Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
 (exception faite des solutions propriétaires ou solutions non déterministes
 de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
 100Mbps sur un LAG 5x100Mbps pour un même flux.

 cordialement,

 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
 Après quelques recherche, j'arrive à la conclusion que la limitation du
 temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
 (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
 de l'OS.

 L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
 les (très) vieux OS, la valeur maxi de window size était 65535 octets
 parce
 que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
 1323 est largement utilisée. Elle introduit un paramètre window size
 scaling factor (8 bits) qui est un multiplcateur de la valeur de window
 size. Le window size est étendu 16Mo au lieu de 64Ko.

 Calculateur de bande passante sur une session TCP :
 https://www.switch.ch/network/tools/tcp_throughput/
 Pour la formule, c'est ici :
 http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
 ghput-for-long-distance-links/

 Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
 faudrait une taille window de ~1800 Ko.

 Il faut regarder les paramètres de l'OS pour voir si les paramètres
 permettent d'avoir une window de cette taille.

 Sur les windows récents, les paramètres sont décrits ici :
 http://www.speedguide.net/articles/windows-8-10-2012-server-
 tcpip-tweaks-5077
 - paragraphe Receive Wi

Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou laurent]

Totalement cohérent alors. 

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a écrit :
>C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ
>en "mono" 100 et des bananes 
>
> Message d'origine 
>De : Louis <luigi.1...@gmail.com> 
>Date : 15/02/2017  17:22  (GMT+01:00) 
>À : sbu123fr <sbu12...@gmail.com> 
>Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG
><frnog@frnog.org> 
>Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais
>plutot 5 x 100Mo 
>
>Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est
>assez fiable. Pas de lecture disque
>Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
>280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
>débit. Avec un transfert multi-session, la tête de lecture/écriture
>d'un disque classique est obligé de faire en permanence des
>aller-retours.
>Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
>BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo
>sur la chaîne de liaison 
>
> Message d'origine --------
>De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> 
>Date : 15/02/2017  16:36  (GMT+01:00) 
>À : frnog@frnog.org 
>Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>  100Mo 
>
>Plus simplement :
>
>Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
>500Mbit/s.
>
>Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
>
>que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
>Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
>compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
>client final crois disposer de 500Mbit/s entre chaque site, mais en 
>réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
>100Mbit/s sur D et que E est au repos.
>
>Je crois avoir compris cela...
>
>
>Le 15/02/2017 à 15:35, Louis a écrit :
>> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
>plus
>> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>>
>> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre
>sites).
>>
>> "Mais mon fournisseur de collecte m'explique que sur son service IP
>MPLS
>> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>sur
>> une session TCP entre 2 liens"
>>
>>
>>
>> Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit
>:
>>
>>> Oui mais non,
>>>
>>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur
>tous les
>>> liens de façon parfaitement aléatoire, souvent les équipements
>balancent le
>>> trafic de manière *déterministe* sur l'un des liens physiques, en se
>basant
>>> sur le couple adresse source-destination, cela peut-être Adresse IP
>source
>>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
>peut-être
>>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>>> exceptions, et sûrement des solutions propriétaires.
>>>
>>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>>> (exception faite des solutions propriétaires ou solutions non
>déterministes
>>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir
>plus de
>>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>>
>>> cordialement,
>>>
>>> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>>>
>>>> Après quelques recherche, j'arrive à la conclusion que la
>limitation du
>>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les
>500Mbps
>>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
>paramètres
>>>> de l'OS.
>>>>
>>>> L'article de 2005 ne précise pas les valeurs de window size
>utilisées. Sur
>>>> les (très) vieux OS, la valeur maxi de window size était 65535
>octets
>>>> parce
>>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant,
>la RFC
>>>> 1323 est largement utilisée. Elle introduit un paramètre window
>size
>>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de
>window
>>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>>
>>>> Calculateur de bande passante sur une session TCP :
>>>> https://www.switch.ch/network/tools/tcp_throu

RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes 

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> 
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>&g

RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

Oui ça ça m inquiet moins ☺

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  17:20  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> 
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>>> tcpip-tweaks-5077
>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>>> paramètre est normal.
>>>
>>> c:\>netsh interface tcp sh

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez
fiable. Pas de lecture disque

Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :

> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
> débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
> disque classique est obligé de faire en permanence des aller-retours.
>
> Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
>
>> Bonjour
>> Avec du multi session on obtient 280Mo
>> Donc pas de souci de 100Mo sur la chaîne de liaison
>>
>>
>>  Message d'origine 
>> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
>> Date : 15/02/2017 16:36 (GMT+01:00)
>> À : frnog@frnog.org
>> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>> 100Mo
>>
>> Plus simplement :
>>
>> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
>> 500Mbit/s.
>>
>> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
>> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>>
>> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
>> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
>> client final crois disposer de 500Mbit/s entre chaque site, mais en
>> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
>> 100Mbit/s sur D et que E est au repos.
>>
>> Je crois avoir compris cela...
>>
>>
>> Le 15/02/2017 à 15:35, Louis a écrit :
>> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
>> plus
>> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>> >
>> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>> >
>> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>> sur
>> > une session TCP entre 2 liens"
>> >
>> >
>> >
>> > Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>> >
>> >> Oui mais non,
>> >>
>> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
>> les
>> >> liens de façon parfaitement aléatoire, souvent les équipements
>> balancent le
>> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
>> basant
>> >> sur le couple adresse source-destination, cela peut-être Adresse IP
>> source
>> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
>> peut-être
>> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> >> exceptions, et sûrement des solutions propriétaires.
>> >>
>> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> >> (exception faite des solutions propriétaires ou solutions non
>> déterministes
>> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
>> de
>> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>> >>
>> >> cordialement,
>> >>
>> >> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>> >>
>> >>> Après quelques recherche, j'arrive à la conclusion que la limitation
>> du
>> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
>> paramètres
>> >>> de l'OS.
>> >>>
>> >>> L'article de 2005 ne précise pas les valeurs de window size
>> utilisées. Sur
>> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> >>> parce
>> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant,
>> la RFC
>> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de
>> window
>> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>> >>>
>> >>> Calculateur de bande passante sur une session TCP :
>> >>> https://www.switch.ch/network/tools/tcp_throughput/
>> >>> Pour la formule, c'est ici :
>> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> >>> ghput-for-long-distance-links/
>&

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
disque classique est obligé de faire en permanence des aller-retours.

Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :

> Bonjour
> Avec du multi session on obtient 280Mo
> Donc pas de souci de 100Mo sur la chaîne de liaison
>
>
>  Message d'origine 
> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
> Date : 15/02/2017 16:36 (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
> 100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
> plus
> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
> >
> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
> >
> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> > une session TCP entre 2 liens"
> >
> >
> >
> > Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
> >
> >> Oui mais non,
> >>
> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
> les
> >> liens de façon parfaitement aléatoire, souvent les équipements
> balancent le
> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
> basant
> >> sur le couple adresse source-destination, cela peut-être Adresse IP
> source
> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
> peut-être
> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> >> exceptions, et sûrement des solutions propriétaires.
> >>
> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> >> (exception faite des solutions propriétaires ou solutions non
> déterministes
> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
> de
> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
> >>
> >> cordialement,
> >>
> >> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
> >>
> >>> Après quelques recherche, j'arrive à la conclusion que la limitation du
> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
> paramètres
> >>> de l'OS.
> >>>
> >>> L'article de 2005 ne précise pas les valeurs de window size utilisées.
> Sur
> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
> >>> parce
> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la
> RFC
> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
> >>>
> >>> Calculateur de bande passante sur une session TCP :
> >>> https://www.switch.ch/network/tools/tcp_throughput/
> >>> Pour la formule, c'est ici :
> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
> >>> ghput-for-long-distance-links/
> >>>
> >>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s
> max), il
> >>> faudrait une taille window de ~1800 Ko.
> >>>
> >>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
> >>> permettent d'avoir une window de cette taille.
> >>>
> >>> Sur les windows récents, les paramètres sont décrits ici :
> >>> http://www.speedguide.net/articles/windows-8-10-2012-server-
> >>> tcpip-tweaks-5077
> >>> - paragraphe Receive Window 

RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

Exacte ! 

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  15:35  (GMT+01:00) 
À : Benjamin Bachelart <b...@bashy.eu> 
Cc : Sylvain sbu <sbu12...@gmail.com>, Xavier HINFRAY <xhinf...@gmail.com>, 
"frnog@FRnOG.org" <frnog@frnog.org>, Michel Hostettler 
<michel.hostett...@telecom-paristech.fr>, frnog-tech <frnog-t...@frnog.org> 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo 

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus 
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS 500Mo 
sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur une session 
TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
Oui mais non,

Sur un LAG, le 
trafic ne se répartie pas - comme par magie - sur tous les liens de 
façon parfaitement aléatoire, souvent les équipements balancent le 
trafic de manière *déterministe* sur l'un des liens physiques, en se 
basant sur le couple adresse source-destination, cela peut-être Adresse 
IP source / Adresse IP destination, ou de même avec l'adresse MAC, 
parfois peut-être par flux (Source IP+Port - Dest IP+Port), il existe 
sûrement des exceptions, et sûrement des solutions propriétaires.

Donc
 avec toutes les tailles de fenêtre tcp, vous ne pourrez pas (exception 
faite des solutions propriétaires ou solutions non déterministes de 
balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de 
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,
2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
Après quelques recherche, j'arrive à la conclusion que la limitation du

temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps

(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres

de l'OS.



L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur

les (très) vieux OS, la valeur maxi de window size était 65535 octets parce

que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC

1323 est largement utilisée. Elle introduit un paramètre window size

scaling factor (8 bits) qui est un multiplcateur de la valeur de window

size. Le window size est étendu 16Mo au lieu de 64Ko.



Calculateur de bande passante sur une session TCP :

https://www.switch.ch/network/tools/tcp_throughput/

Pour la formule, c'est ici :

http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/



Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il

faudrait une taille window de ~1800 Ko.



Il faut regarder les paramètres de l'OS pour voir si les paramètres

permettent d'avoir une window de cette taille.



Sur les windows récents, les paramètres sont décrits ici :

http://www.speedguide.net/articles/windows-8-10-2012-server-tcpip-tweaks-5077

- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le

paramètre est normal.



c:\>netsh interface tcp show global



Paramètres TCP globaux

--

État de mise à l'échelle côté réception     : enabled

État de déchargement Chimney     : automatic

État NetDMA                        : enabled

Accès direct au cache            : disabled

*Réglage auto fenêtre de réception   : normal*



Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window

maxi associée à ce paramètre "normal".



Il faudrait tester un téléchargement depuis un windows d'un gros fichier

avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On

verrait quel débit on obtient et Wireshark pourrait donner la taille de

window.



Louis



Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :



> 40Kms grand max...

>

> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a écrit :

>

>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.

>> Donc tout dépend de la distance entre le point de départ et d'arrivée.

>>

>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <

>> michel.hostett...@telecom-paristech.fr> a écrit :

>>>

>>> Bonjour,

>>>

>>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?

>>>

>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>>> depuis 12 ans.

>>>

>>> Cordialement,

>>> Michel

>>>

>>> ----- Mail original -

>>> De: "Louis" <luigi.1...@gmail.com>

>>> À: "sbu123fr" <sbu12...@gmail.com>

>>> Cc: "f

RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> 
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>>> tcpip-tweaks-5077
>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>>> paramètre est normal.
>>>
>>> c:\>netsh interface tcp show global
>>>
>>> Paramètres TCP globaux
>>> --
>>> État de mise à l'échelle côté réception : enabled
>>> État de déchargement Chimney : automatic
>>> État NetDMA    : enabled
>>> Accès direct au cache    : disabled
>>> *Réglage auto fenêtre de réception   : normal*
>>>
>>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>>> window
>>> maxi associée à ce paramètre "normal".
>>>
>>> Il faudrait tester un téléchargement depu

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou Laurent]

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.


Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.


Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.


Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
une session TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :


Oui mais non,

Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
liens de façon parfaitement aléatoire, souvent les équipements balancent le
trafic de manière *déterministe* sur l'un des liens physiques, en se basant
sur le couple adresse source-destination, cela peut-être Adresse IP source
/ Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
exceptions, et sûrement des solutions propriétaires.

Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
(exception faite des solutions propriétaires ou solutions non déterministes
de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,

2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:


Après quelques recherche, j'arrive à la conclusion que la limitation du
temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
de l'OS.

L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
les (très) vieux OS, la valeur maxi de window size était 65535 octets
parce
que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
1323 est largement utilisée. Elle introduit un paramètre window size
scaling factor (8 bits) qui est un multiplcateur de la valeur de window
size. Le window size est étendu 16Mo au lieu de 64Ko.

Calculateur de bande passante sur une session TCP :
https://www.switch.ch/network/tools/tcp_throughput/
Pour la formule, c'est ici :
http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
ghput-for-long-distance-links/

Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
faudrait une taille window de ~1800 Ko.

Il faut regarder les paramètres de l'OS pour voir si les paramètres
permettent d'avoir une window de cette taille.

Sur les windows récents, les paramètres sont décrits ici :
http://www.speedguide.net/articles/windows-8-10-2012-server-
tcpip-tweaks-5077
- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
paramètre est normal.

c:\>netsh interface tcp show global

Paramètres TCP globaux
--
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA: enabled
Accès direct au cache: disabled
*Réglage auto fenêtre de réception   : normal*

Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
window
maxi associée à ce paramètre "normal".

Il faudrait tester un téléchargement depuis un windows d'un gros fichier
avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
On
verrait quel débit on obtient et Wireshark pourrait donner la taille de
window.

Louis

Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :


40Kms grand max...

Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a

écrit :

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
Donc tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
michel.hostett...@telecom-paristech.fr> a écrit :

Bonjour,

Est-ce encore plausible de nos jours, un temps d'aller retour de 30

ms ?

Le document daterait de janvier 2005. Les réseaux n'ont-ils pas

évolué depuis 12 ans.

Cordialement,
Michel

- Mail original -
De: "Louis" <luigi.1...@gmail.com>
À: "sbu123fr" <sbu12...@gmail.com>
Cc: "frnog-tech" <frnog-t...@frnog.org>
Envoyé: Mercredi 15 Février 2017 10:28:06
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x

100Mo

Probab

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
une session TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :

> Oui mais non,
>
> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
> liens de façon parfaitement aléatoire, souvent les équipements balancent le
> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
> sur le couple adresse source-destination, cela peut-être Adresse IP source
> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> exceptions, et sûrement des solutions propriétaires.
>
> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> (exception faite des solutions propriétaires ou solutions non déterministes
> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>
> cordialement,
>
> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>
>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>> de l'OS.
>>
>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> parce
>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>
>> Calculateur de bande passante sur une session TCP :
>> https://www.switch.ch/network/tools/tcp_throughput/
>> Pour la formule, c'est ici :
>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> ghput-for-long-distance-links/
>>
>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>> faudrait une taille window de ~1800 Ko.
>>
>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>> permettent d'avoir une window de cette taille.
>>
>> Sur les windows récents, les paramètres sont décrits ici :
>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>> tcpip-tweaks-5077
>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>> paramètre est normal.
>>
>> c:\>netsh interface tcp show global
>>
>> Paramètres TCP globaux
>> --
>> État de mise à l'échelle côté réception : enabled
>> État de déchargement Chimney : automatic
>> État NetDMA: enabled
>> Accès direct au cache: disabled
>> *Réglage auto fenêtre de réception   : normal*
>>
>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>> window
>> maxi associée à ce paramètre "normal".
>>
>> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
>> On
>> verrait quel débit on obtient et Wireshark pourrait donner la taille de
>> window.
>>
>> Louis
>>
>> Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :
>>
>> > 40Kms grand max...
>> >
>> > Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a
>> écrit :
>> >
>> >> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> >> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>> >>
>> >> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> >> michel.hostett...@telecom-paristech.fr> a écrit :
>> >>>
>> >>> Bonjour,
>> >>>
>> >>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30
>> ms ?
>> >>>
>> >>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas
>> évolué depuis 12 ans.
>> >>>
>> >>> Cordialement,
>> >>> Michel
>> >>>
&

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Benjamin Bachelart]

Oui mais non,

Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
liens de façon parfaitement aléatoire, souvent les équipements balancent le
trafic de manière *déterministe* sur l'un des liens physiques, en se basant
sur le couple adresse source-destination, cela peut-être Adresse IP source
/ Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
exceptions, et sûrement des solutions propriétaires.

Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas (exception
faite des solutions propriétaires ou solutions non déterministes de
balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,

2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:

> Après quelques recherche, j'arrive à la conclusion que la limitation du
> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
> de l'OS.
>
> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
> les (très) vieux OS, la valeur maxi de window size était 65535 octets parce
> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
> 1323 est largement utilisée. Elle introduit un paramètre window size
> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
> size. Le window size est étendu 16Mo au lieu de 64Ko.
>
> Calculateur de bande passante sur une session TCP :
> https://www.switch.ch/network/tools/tcp_throughput/
> Pour la formule, c'est ici :
> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-
> throughput-for-long-distance-links/
>
> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
> faudrait une taille window de ~1800 Ko.
>
> Il faut regarder les paramètres de l'OS pour voir si les paramètres
> permettent d'avoir une window de cette taille.
>
> Sur les windows récents, les paramètres sont décrits ici :
> http://www.speedguide.net/articles/windows-8-10-2012-
> server-tcpip-tweaks-5077
> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
> paramètre est normal.
>
> c:\>netsh interface tcp show global
>
> Paramètres TCP globaux
> --
> État de mise à l'échelle côté réception : enabled
> État de déchargement Chimney : automatic
> État NetDMA: enabled
> Accès direct au cache: disabled
> *Réglage auto fenêtre de réception   : normal*
>
> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window
> maxi associée à ce paramètre "normal".
>
> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On
> verrait quel débit on obtient et Wireshark pourrait donner la taille de
> window.
>
> Louis
>
> Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :
>
> > 40Kms grand max...
> >
> > Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a écrit
> :
> >
> >> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
> >> Donc tout dépend de la distance entre le point de départ et d'arrivée.
> >>
> >> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
> >> michel.hostett...@telecom-paristech.fr> a écrit :
> >>>
> >>> Bonjour,
> >>>
> >>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
> ?
> >>>
> >>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
> depuis 12 ans.
> >>>
> >>> Cordialement,
> >>> Michel
> >>>
> >>> - Mail original -
> >>> De: "Louis" <luigi.1...@gmail.com>
> >>> À: "sbu123fr" <sbu12...@gmail.com>
> >>> Cc: "frnog-tech" <frnog-t...@frnog.org>
> >>> Envoyé: Mercredi 15 Février 2017 10:28:06
> >>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
> 100Mo
> >>>
> >>> Probablement oui :
> >>>
> >>> http://smutz.us/techtips/NetworkLatency.html
> >>>
> >>> *Round trip latency*
> >>>
> >>> *TCP Throughput with no packet loss*
> >>>
> >>> *TCP Throughput with 2% packet loss*
> >>>
> >>> 0 ms
> >>>
> >>> 93.50 Mbps
> >>>
> >>> 3.72 Mbps
> >>>
>

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Après quelques recherche, j'arrive à la conclusion que la limitation du
temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
de l'OS.

L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
les (très) vieux OS, la valeur maxi de window size était 65535 octets parce
que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
1323 est largement utilisée. Elle introduit un paramètre window size
scaling factor (8 bits) qui est un multiplcateur de la valeur de window
size. Le window size est étendu 16Mo au lieu de 64Ko.

Calculateur de bande passante sur une session TCP :
https://www.switch.ch/network/tools/tcp_throughput/
Pour la formule, c'est ici :
http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
faudrait une taille window de ~1800 Ko.

Il faut regarder les paramètres de l'OS pour voir si les paramètres
permettent d'avoir une window de cette taille.

Sur les windows récents, les paramètres sont décrits ici :
http://www.speedguide.net/articles/windows-8-10-2012-server-tcpip-tweaks-5077
- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
paramètre est normal.

c:\>netsh interface tcp show global

Paramètres TCP globaux
--
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA: enabled
Accès direct au cache: disabled
*Réglage auto fenêtre de réception   : normal*

Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window
maxi associée à ce paramètre "normal".

Il faudrait tester un téléchargement depuis un windows d'un gros fichier
avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On
verrait quel débit on obtient et Wireshark pourrait donner la taille de
window.

Louis

Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :

> 40Kms grand max...
>
> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a écrit :
>
>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>>
>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> michel.hostett...@telecom-paristech.fr> a écrit :
>>>
>>> Bonjour,
>>>
>>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?
>>>
>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>>> depuis 12 ans.
>>>
>>> Cordialement,
>>> Michel
>>>
>>> - Mail original -----
>>> De: "Louis" <luigi.1...@gmail.com>
>>> À: "sbu123fr" <sbu12...@gmail.com>
>>> Cc: "frnog-tech" <frnog-t...@frnog.org>
>>> Envoyé: Mercredi 15 Février 2017 10:28:06
>>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>
>>> Probablement oui :
>>>
>>> http://smutz.us/techtips/NetworkLatency.html
>>>
>>> *Round trip latency*
>>>
>>> *TCP Throughput with no packet loss*
>>>
>>> *TCP Throughput with 2% packet loss*
>>>
>>> 0 ms
>>>
>>> 93.50 Mbps
>>>
>>> 3.72 Mbps
>>>
>>> 30 ms
>>>
>>> 16.20 Mbps
>>>
>>> 1.63 Mbps
>>>
>>> 60 ms
>>>
>>> 8.07 Mbps
>>>
>>> 1.33 Mbps
>>>
>>> 90 ms
>>>
>>> 5.32 Mbps
>>>
>>> 0.85 Mbps
>>>
>>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>>>
>>> Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :
>>>
>>>  Grand merci.
>>>>  Tu pense que sur des liens en île de france la latence est telle que le
>>>>  trafic peut être divisé par 4-5?
>>>>  Cdt
>>>>  Sbu
>>>>
>>>>
>>>>
>>>>   Message d'origine 
>>>>  De : Louis <luigi.1...@gmail.com>
>>>>  Date : 14/02/2017 18:05 (GMT+01:00)
>>>>  À : Sylvain sbu <sbu12...@gmail.com>
>>>>  Cc : frnog-tech <frnog-t...@frnog.org>
>>>>  Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>>
>>>>  cela dépend surtout du temps de réponse sur les liens. On perd en débit à
>>>>  cause des acquittements nécessaires à TCP. Les

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Sylvain sbu]

40Kms grand max...

Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a écrit :

> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>
> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
> michel.hostett...@telecom-paristech.fr> a écrit :
>>
>> Bonjour,
>>
>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?
>>
>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>> depuis 12 ans.
>>
>> Cordialement,
>> Michel
>>
>> - Mail original -
>> De: "Louis" <luigi.1...@gmail.com>
>> À: "sbu123fr" <sbu12...@gmail.com>
>> Cc: "frnog-tech" <frnog-t...@frnog.org>
>> Envoyé: Mercredi 15 Février 2017 10:28:06
>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> Probablement oui :
>>
>> http://smutz.us/techtips/NetworkLatency.html
>>
>> *Round trip latency*
>>
>> *TCP Throughput with no packet loss*
>>
>> *TCP Throughput with 2% packet loss*
>>
>> 0 ms
>>
>> 93.50 Mbps
>>
>> 3.72 Mbps
>>
>> 30 ms
>>
>> 16.20 Mbps
>>
>> 1.63 Mbps
>>
>> 60 ms
>>
>> 8.07 Mbps
>>
>> 1.33 Mbps
>>
>> 90 ms
>>
>> 5.32 Mbps
>>
>> 0.85 Mbps
>>
>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>>
>> Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :
>>
>>  Grand merci.
>>>  Tu pense que sur des liens en île de france la latence est telle que le
>>>  trafic peut être divisé par 4-5?
>>>  Cdt
>>>  Sbu
>>>
>>>
>>>
>>>   Message d'origine 
>>>  De : Louis <luigi.1...@gmail.com>
>>>  Date : 14/02/2017 18:05 (GMT+01:00)
>>>  À : Sylvain sbu <sbu12...@gmail.com>
>>>  Cc : frnog-tech <frnog-t...@frnog.org>
>>>  Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>
>>>  cela dépend surtout du temps de réponse sur les liens. On perd en débit à
>>>  cause des acquittements nécessaires à TCP. Les durées d'acquittement
>>>  s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
>>>  utile ne transite.
>>>
>>>  Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>>>  performances en augmentant le nombre de paquets reçus avant acquittements.
>>>  Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>>>
>>>  Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
>>>  la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
>>>  qu'on peut tuner je crois.
>>>
>>>  L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
>>>  trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
>>>  autre sur les paramètres window TCP.
>>>
>>>  Je suppose que le débit est voulu pour des gros transferts de fichier.
>>>  Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
>>>  transfert du même fichier sur plusieurs sessions TCP.
>>>
>>>  cordialement,
>>>
>>>  Louis
>>>
>>>
>>>
>>>
>>>  Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit :
>>>
>>>  Bonjour,
>>>>  Non rien a voir avec du hachage car en changeant un paramétrè de
>>>>  "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>>>>  cdt
>>>>  SBU
>>>>
>>>>  Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com> a
>>>>  écrit :
>>>>
>>>>  Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>>>>  sbu12...@gmail.com] a écrit:
>>>>>
>>>>>>  Bonjour,
>>>>>>  Je ne suis pas spécialiste du transport IP.
>>>>>>  Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>>>>>  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>>>>>
>>>>>  sur
>>>>>
>>>>>>  une session TCP entre 2 liens
>>>>>>
>>>>>
>>>>>  Tes "4 liens", je suppose que c'est "

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Michel Hostettler]

Le monde est mal fichu.
Les technologies évolues, mais pas les hommes, ni la vitesse de la lumière. 
Pour les femmes, je n'ose pas me prononcer.

Je me suis trompé d'échelle. La mienne était cassée.
Pour 5 µs / km, avec 30 ms, nous avons 6000 km de fibre optique

soit Paris - Campagnole et Campagnole - Paris

Cordialememt,
Michel (l'un d'eux)

- Mail original -
De: "Xavier HINFRAY" <xhinf...@gmail.com>
À: frnog@frnog.org, "Michel Hostettler" 
<michel.hostett...@telecom-paristech.fr>, "Louis" <luigi.1...@gmail.com>
Cc: "sbu123fr" <sbu12...@gmail.com>, "frnog-tech" <frnog-t...@frnog.org>
Envoyé: Mercredi 15 Février 2017 13:03:49
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière. Donc 
tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler 
<michel.hostett...@telecom-paristech.fr> a écrit :
>Bonjour,
>
>Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
>?
>
>Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
>depuis 12 ans.
>
>Cordialement,
>Michel
>
>- Mail original -
>De: "Louis" <luigi.1...@gmail.com>
>À: "sbu123fr" <sbu12...@gmail.com>
>Cc: "frnog-tech" <frnog-t...@frnog.org>
>Envoyé: Mercredi 15 Février 2017 10:28:06
>Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>100Mo
>
>Probablement oui :
>
>http://smutz.us/techtips/NetworkLatency.html
>
>*Round trip latency*
>
>*TCP Throughput with no packet loss*
>
>*TCP Throughput with 2% packet loss*
>
>0 ms
>
>93.50 Mbps
>
>3.72 Mbps
>
>30 ms
>
>16.20 Mbps
>
>1.63 Mbps
>
>60 ms
>
>8.07 Mbps
>
>1.33 Mbps
>
>90 ms
>
>5.32 Mbps
>
>0.85 Mbps
>
>Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>
>Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :
>
>> Grand merci.
>> Tu pense que sur des liens en île de france la latence est telle que
>le
>> trafic peut être divisé par 4-5?
>> Cdt
>> Sbu
>>
>>
>>
>>  Message d'origine 
>> De : Louis <luigi.1...@gmail.com>
>> Date : 14/02/2017 18:05 (GMT+01:00)
>> À : Sylvain sbu <sbu12...@gmail.com>
>> Cc : frnog-tech <frnog-t...@frnog.org>
>> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> cela dépend surtout du temps de réponse sur les liens. On perd en
>débit à
>> cause des acquittements nécessaires à TCP. Les durées d'acquittement
>> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de
>donnée
>> utile ne transite.
>>
>> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>> performances en augmentant le nombre de paquets reçus avant
>acquittements.
>> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les
>liens.
>>
>> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité
>de
>> la connexion. Les derniers OS ont des valeurs par défaut optimisées
>mais
>> qu'on peut tuner je crois.
>>
>> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs
>de
>> trafic. Il existe pas mal d'équipements sur le marché qui jouent
>entre
>> autre sur les paramètres window TCP.
>>
>> Je suppose que le débit est voulu pour des gros transferts de
>fichier.
>> Souvent, la solution adoptée est d'utiliser des outils qui
>parallélisent le
>> transfert du même fichier sur plusieurs sessions TCP.
>>
>> cordialement,
>>
>> Louis
>>
>>
>>
>>
>> Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit
>:
>>
>>> Bonjour,
>>> Non rien a voir avec du hachage car en changeant un paramétrè de
>>> "fenêtre" il est possible d'augmenter le max traffic a 75% des
>500Mo.
>>> cdt
>>> SBU
>>>
>>> Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com>
>a
>>> écrit :
>>>
>>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>>> sbu12...@gmail.com] a écrit:
>>>> > Bonjour,
>>>> > Je ne suis pas spécialiste du transport IP.
>>>> > Mais mon fournisseur de collecte m'explique que sur son service
>IP MPLS
>>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic
>max
>>>> sur
>>>> > une session TC

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Xavier HINFRAY]

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière. Donc 
tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler 
<michel.hostett...@telecom-paristech.fr> a écrit :
>Bonjour,
>
>Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
>?
>
>Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
>depuis 12 ans.
>
>Cordialement,
>Michel
>
>- Mail original -
>De: "Louis" <luigi.1...@gmail.com>
>À: "sbu123fr" <sbu12...@gmail.com>
>Cc: "frnog-tech" <frnog-t...@frnog.org>
>Envoyé: Mercredi 15 Février 2017 10:28:06
>Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>100Mo
>
>Probablement oui :
>
>http://smutz.us/techtips/NetworkLatency.html
>
>*Round trip latency*
>
>*TCP Throughput with no packet loss*
>
>*TCP Throughput with 2% packet loss*
>
>0 ms
>
>93.50 Mbps
>
>3.72 Mbps
>
>30 ms
>
>16.20 Mbps
>
>1.63 Mbps
>
>60 ms
>
>8.07 Mbps
>
>1.33 Mbps
>
>90 ms
>
>5.32 Mbps
>
>0.85 Mbps
>
>Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>
>Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :
>
>> Grand merci.
>> Tu pense que sur des liens en île de france la latence est telle que
>le
>> trafic peut être divisé par 4-5?
>> Cdt
>> Sbu
>>
>>
>>
>>  Message d'origine 
>> De : Louis <luigi.1...@gmail.com>
>> Date : 14/02/2017 18:05 (GMT+01:00)
>> À : Sylvain sbu <sbu12...@gmail.com>
>> Cc : frnog-tech <frnog-t...@frnog.org>
>> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> cela dépend surtout du temps de réponse sur les liens. On perd en
>débit à
>> cause des acquittements nécessaires à TCP. Les durées d'acquittement
>> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de
>donnée
>> utile ne transite.
>>
>> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>> performances en augmentant le nombre de paquets reçus avant
>acquittements.
>> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les
>liens.
>>
>> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité
>de
>> la connexion. Les derniers OS ont des valeurs par défaut optimisées
>mais
>> qu'on peut tuner je crois.
>>
>> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs
>de
>> trafic. Il existe pas mal d'équipements sur le marché qui jouent
>entre
>> autre sur les paramètres window TCP.
>>
>> Je suppose que le débit est voulu pour des gros transferts de
>fichier.
>> Souvent, la solution adoptée est d'utiliser des outils qui
>parallélisent le
>> transfert du même fichier sur plusieurs sessions TCP.
>>
>> cordialement,
>>
>> Louis
>>
>>
>>
>>
>> Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit
>:
>>
>>> Bonjour,
>>> Non rien a voir avec du hachage car en changeant un paramétrè de
>>> "fenêtre" il est possible d'augmenter le max traffic a 75% des
>500Mo.
>>> cdt
>>> SBU
>>>
>>> Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com>
>a
>>> écrit :
>>>
>>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>>> sbu12...@gmail.com] a écrit:
>>>> > Bonjour,
>>>> > Je ne suis pas spécialiste du transport IP.
>>>> > Mais mon fournisseur de collecte m'explique que sur son service
>IP MPLS
>>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic
>max
>>>> sur
>>>> > une session TCP entre 2 liens
>>>>
>>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>>
>>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>>> Elle correspond aux algorithmes de répartition entre les liens
>faisant
>>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le
>trafic
>>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>>> Tut te trouves alors limité par la capacité physique du lien
>>>> sélectionné.
>>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir
>une
>>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>>
>>>>
>>>> --
>>>> Dominique Rousseau
>>>> Neuronnexion, Prestataire Internet & Intranet
>>>> 21 rue Frédéric Petit - 8 Amiens
>>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 -
>http://www.neuronnexion.coop
>>>>
>>>>
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/
>>>>
>>>
>>>
>>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/
>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Michel Hostettler]

Bonjour,

Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?

Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué depuis 
12 ans.

Cordialement,
Michel

- Mail original -
De: "Louis" <luigi.1...@gmail.com>
À: "sbu123fr" <sbu12...@gmail.com>
Cc: "frnog-tech" <frnog-t...@frnog.org>
Envoyé: Mercredi 15 Février 2017 10:28:06
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput

Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :

> Grand merci.
> Tu pense que sur des liens en île de france la latence est telle que le
> trafic peut être divisé par 4-5?
> Cdt
> Sbu
>
>
>
>  Message d'origine 
> De : Louis <luigi.1...@gmail.com>
> Date : 14/02/2017 18:05 (GMT+01:00)
> À : Sylvain sbu <sbu12...@gmail.com>
> Cc : frnog-tech <frnog-t...@frnog.org>
> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> cela dépend surtout du temps de réponse sur les liens. On perd en débit à
> cause des acquittements nécessaires à TCP. Les durées d'acquittement
> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
> utile ne transite.
>
> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
> performances en augmentant le nombre de paquets reçus avant acquittements.
> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>
> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
> la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
> qu'on peut tuner je crois.
>
> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
> trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
> autre sur les paramètres window TCP.
>
> Je suppose que le débit est voulu pour des gros transferts de fichier.
> Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
> transfert du même fichier sur plusieurs sessions TCP.
>
> cordialement,
>
> Louis
>
>
>
>
> Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit :
>
>> Bonjour,
>> Non rien a voir avec du hachage car en changeant un paramétrè de
>> "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>> cdt
>> SBU
>>
>> Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com> a
>> écrit :
>>
>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>> sbu12...@gmail.com] a écrit:
>>> > Bonjour,
>>> > Je ne suis pas spécialiste du transport IP.
>>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>> sur
>>> > une session TCP entre 2 liens
>>>
>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>
>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>> Elle correspond aux algorithmes de répartition entre les liens faisant
>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>> Tut te trouves alors limité par la capacité physique du lien
>>> sélectionné.
>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>
>>>
>>> --
>>> Dominique Rousseau
>>> Neuronnexion, Prestataire Internet & Intranet
>>> 21 rue Frédéric Petit - 8 Amiens
>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput

Le 14 février 2017 à 18:57, sbu123fr  a écrit :

> Grand merci.
> Tu pense que sur des liens en île de france la latence est telle que le
> trafic peut être divisé par 4-5?
> Cdt
> Sbu
>
>
>
>  Message d'origine 
> De : Louis 
> Date : 14/02/2017 18:05 (GMT+01:00)
> À : Sylvain sbu 
> Cc : frnog-tech 
> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> cela dépend surtout du temps de réponse sur les liens. On perd en débit à
> cause des acquittements nécessaires à TCP. Les durées d'acquittement
> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
> utile ne transite.
>
> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
> performances en augmentant le nombre de paquets reçus avant acquittements.
> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>
> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
> la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
> qu'on peut tuner je crois.
>
> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
> trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
> autre sur les paramètres window TCP.
>
> Je suppose que le débit est voulu pour des gros transferts de fichier.
> Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
> transfert du même fichier sur plusieurs sessions TCP.
>
> cordialement,
>
> Louis
>
>
>
>
> Le 14 février 2017 à 16:45, Sylvain sbu  a écrit :
>
>> Bonjour,
>> Non rien a voir avec du hachage car en changeant un paramétrè de
>> "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>> cdt
>> SBU
>>
>> Le 14 février 2017 à 16:41, Dominique Rousseau  a
>> écrit :
>>
>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>> sbu12...@gmail.com] a écrit:
>>> > Bonjour,
>>> > Je ne suis pas spécialiste du transport IP.
>>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>> sur
>>> > une session TCP entre 2 liens
>>>
>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>
>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>> Elle correspond aux algorithmes de répartition entre les liens faisant
>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>> Tut te trouves alors limité par la capacité physique du lien
>>> sélectionné.
>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>
>>>
>>> --
>>> Dominique Rousseau
>>> Neuronnexion, Prestataire Internet & Intranet
>>> 21 rue Frédéric Petit - 8 Amiens
>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/