Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
Attention à l'algo TCP utilisé, il en existe plusieurs et certains fonctionnent bien mieux avec fort débit + fort RTT. (chaque extrémité gère son algo localement pour les paquets émis et à réémettre) Quelques notes assez anciennes mais toujours utiles : Linux :: Algos de contrôle de congestion TCP Source : http://linuxgazette.net/135/pfeiffer.html # Algos dispo Voir la liste des algos dispo sur ce linux : ls /lib/modules/`uname -r`/kernel/net/ipv4/ ls /lib/modules/3.2.0-69-generic/kernel/net/ipv4/ tcp_bic.ko tcp_diag.ko tcp_highspeed.ko tcp_htcp.ko tcp_hybla.ko tcp_illinois.ko tcp_lp.ko tcp_probe.ko tcp_scalable.ko tcp_vegas.ko tcp_veno.ko tcp_westwood.ko tcp_yeah.ko De base sur un ubuntu 12.04 : cubic Exemple de cas de pertes pertes de paquets sur un réseau d'une mauvaise DSP, iperf en cubic : 8mbps. Le passage en scalable a permis de monter à 15mbps # Changer l’algo par défaut echo "scalable" > /proc/sys/net/ipv4/tcp_congestion_control # iperf iperf peut aussi changer l’algo à la volée iperf -Z scalable Le ven. 13 déc. 2019 à 10:26, Frederic Dumas a écrit : > > > Merci Fabien, Philippe, Raphaël pour vos réponses. > > Par le calcul, je n'arrive pas à retrouver vos conclusions. > > Au moment des tests, j'avais un rtt de 174ms en moyenne et un jitter de > 10ms. J'étais cappé à 132Mbps (pas MBps, coquille). Et aucun paquet n'a > été réémis; pas de pertes. Si le facteur qui a limité le débit, c'est > comme vous le suggérez la fenêtre TCP et non pas un shapping du trafic > par l'opérateur, la fenêtre aurait été à ce moment là de ~2,8Mio. Je > lisais que sa taille peut théoriquement aller jusqu'au Gio pour laisser > le débit augmenter malgré la latence. > > Est-ce que l'explication par le fenêtre trop petite est vraiment la > bonne pour un trafic tcp wan transatlantique cappé à ~130Mbps ? > > > Frédéric. > > -- > Frederic Dumas > f.du...@ellis.siteparc.fr > > > > > >> Bonjour, > >> > >>> iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre > >>> iperf.he.net et ma machine. C'est > >>> suffisamment haut pour ne pas poser de problème. Par curiosité, > >>> est-il possible d'identifier aux > >>> alentours de quel hop le shaping serait appliqué ? > > >> J'ai l'impression que ton problème de TCP shapé n'en est pas un, que > >> c'est juste l'effet de la latence que tu mesures... > >> En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la > >> limite un WAN national. > >> Pour la longue distance, si tu veux mesurer une bande passante max, > >> c'est forcément avec de l'UDP. > > > > > Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt > > long, multiplie le nombre de flows: > > > > -P, --parallel # number of parallel client streams to run > > > > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
Merci Fabien, Philippe, Raphaël pour vos réponses. Par le calcul, je n'arrive pas à retrouver vos conclusions. Au moment des tests, j'avais un rtt de 174ms en moyenne et un jitter de 10ms. J'étais cappé à 132Mbps (pas MBps, coquille). Et aucun paquet n'a été réémis; pas de pertes. Si le facteur qui a limité le débit, c'est comme vous le suggérez la fenêtre TCP et non pas un shapping du trafic par l'opérateur, la fenêtre aurait été à ce moment là de ~2,8Mio. Je lisais que sa taille peut théoriquement aller jusqu'au Gio pour laisser le débit augmenter malgré la latence. Est-ce que l'explication par le fenêtre trop petite est vraiment la bonne pour un trafic tcp wan transatlantique cappé à ~130Mbps ? Frédéric. -- Frederic Dumas f.du...@ellis.siteparc.fr Bonjour, iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de problème. Par curiosité, est-il possible d'identifier aux alentours de quel hop le shaping serait appliqué ? J'ai l'impression que ton problème de TCP shapé n'en est pas un, que c'est juste l'effet de la latence que tu mesures... En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la limite un WAN national. Pour la longue distance, si tu veux mesurer une bande passante max, c'est forcément avec de l'UDP. Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt long, multiplie le nombre de flows: -P, --parallel # number of parallel client streams to run --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
Bonjour, iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de problème. Par curiosité, est-il possible d'identifier aux alentours de quel hop le shaping serait appliqué ? J'ai l'impression que ton problème de TCP shapé n'en est pas un, que c'est juste l'effet de la latence que tu mesures... En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la limite un WAN national. Pour la longue distance, si tu veux mesurer une bande passante max, c'est forcément avec de l'UDP. Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt long, multiplie le nombre de flows: -P, --parallel # number of parallel client streams to run + --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
Bonjour, > iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre > iperf.he.net et ma machine. C'est > suffisamment haut pour ne pas poser de problème. Par curiosité, est-il > possible d'identifier aux > alentours de quel hop le shaping serait appliqué ? J'ai l'impression que ton problème de TCP shapé n'en est pas un, que c'est juste l'effet de la latence que tu mesures... En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la limite un WAN national. Pour la longue distance, si tu veux mesurer une bande passante max, c'est forcément avec de l'UDP. Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
On 12/12/2019 10:19, Frederic Dumas wrote: C'est une question de curiosité, pas un problème réel dans le cas présent. En général le rtt (et donc la vitesse de la lumière), et le loss sont une bonne indication du débit théorique que tu peux atteindre en TCP ,;) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
Bonjour, iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de problème. Par curiosité, est-il possible d'identifier aux alentours de quel hop le shaping serait appliqué ? D'après le looking glass de HE, les paquets allant de la Californie vers l'Europe ne traversent que deux AS: HE et celui de mon FAI (UPC). Ça ne nous laisse pas beaucoup de coupables. Sans sondes le long du chemin, je ne vois pas comment en savoir plus. Existe-t-il un outil publiquement accessible du style des sondes Atlas, non pas pour regarder les annonces BGP, mais pour tester les débits depuis différents points de l'internet? Je préfère poser la question que de conclure trop vite. C'est une question de curiosité, pas un problème réel dans le cas présent. Bonne journée. $ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R Connecting to host iperf.he.net, port 5201 Reverse mode, remote host iperf.he.net is sending [SNIP] - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 472 MBytes 132 Mbits/sec0 sender [ 4] 0.00-30.00 sec 473 MBytes 132 Mbits/sec receiver $ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R -P2 Connecting to host iperf.he.net, port 5201 Reverse mode, remote host iperf.he.net is sending [SNIP] - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 456 MBytes 128 Mbits/sec0 sender [ 4] 0.00-30.00 sec 457 MBytes 128 Mbits/sec receiver [ 6] 0.00-30.00 sec 456 MBytes 128 Mbits/sec0 sender [ 6] 0.00-30.00 sec 457 MBytes 128 Mbits/sec receiver [SUM] 0.00-30.00 sec 912 MBytes 255 Mbits/sec0 sender [SUM] 0.00-30.00 sec 914 MBytes 256 Mbits/sec receiver -- Frederic Dumas f.du...@ellis.siteparc.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
