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 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 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 - 80000 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/
>>>
>>
> ---------------------------
> 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/

Répondre à