Lenteur FTP difficile a comprendre

Salut,

On Fri, 3 Oct 2003 12:24:06 +0200, Bill <g.corbehem@wanadoo.fr> wrote:

j'ai du mal a comprendre ceci.

C'est pourtant simple :-)

J'ai un VPN entre 2 reseau distant. (IPSEC FreeS/WAN )
L'un est derriere une passerelle sous Linux directement connectée a
internet.
L'autre est derriere une passerelle Linux, elle meme derriere une boite
noire connectée au satellite. Le satellite assure un download et un
upload
plutot impressionnant.

Oui, mais une latence très élevée (surtout que dans ce cas les deux sens
de transmission se font via le satellite).

Le souci est le suivant, si j'ouvre une session FTP entre une machine de
l'intranet 1 et une autre de l intranet 2 , je monte a peine a 10-15
Ko/s
(en download)
Je suis logiquement censé atteindre 64 Ko/S max (ADSL pack wanadoo 1
sur
la passerelle)

Ce qui est encore plus drole, c'est que si j ouvre 2 session FTP en
parallele, j'ai a peu pres 2 fois 10-15 Ko/S , ce qui prouvre que le
satellite en a encore sous le capot :o)

C'est simple: le débit maximal sur une session TCP est déterminé non
seulement par le débit des liaisons sur le chemin, mais aussi par la
latence totale de bout en bout. Plus la latence est élevée, plus le débit
(par session TCP) baisse.

Le problème vient du "windowing": quand une machine envoie des données en
TCP à une autre, elle attend un acquittement avant de continuer (pour
éviter de tout déverser dans un trou noir pour rien). Pour éviter le genre
"j'envoie un paquet, j'attends la réponse, j'envoie un autre paquet,
j'attends la réponse...", qui serait *très* lent (voir notre bon vieil ami
Kermit pour ceux qui étaient déjà nés), TCP envoie des paquets à
concurrence de la taille de la "fenêtre" sans attendre d'acquittement.
Mais il ne continuera à envoyer (au delà de la taille de la fenêtre)
qu'une fois qu'il aura commencé à recevoir les acquittements pour les
premiers paquets. En gros, il n'y a jamais plus que la taille de la
fenêtre de paquets envoyés et pas encore acquittés.

Donc si les acquittements mettent du temps à revenir, l'émetteur peut
attendre pas mal de temps avant de continuer à envoyer.

La taille de la fenêtre peut varier pas mal d'une machine à l'autre (OS,
config...). On voit aussi bien 8K que 64K, par exemple. Et avec 8K, et une
latence de l'ordre de 500 ms, on ne dépasse pas 16 Ko/seconde.

Pour améliorer les choses, tu peux essayer d'augmenter les tailles des
fenêtres TCP sur les machines (la source et la destination de la session
FTP, les machines intermédiaires n'ont pas d'importance). Si tu nous dis
le type de machine, on pourra (peut-être) te dire comment faire.

Hop,

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Oui, mais une latence très élevée (surtout que dans ce cas les deux sens
de transmission se font via le satellite).

Tout a fait , oui :o)
Le but principal de ce VPN , sera de la connexion HTTP , partage SMB ,
connexion Oracle , et autres transferts FTP

Par contre , en attendant, je configure le systeme a distance (plus de 450
km de distance).... ce qui implique du telnet.....et la.... la latence
propre au satellite se fait cruellement sentir :o(

Le problème vient du "windowing": quand une machine envoie des données en
(...)
Donc si les acquittements mettent du temps à revenir, l'émetteur peut
attendre pas mal de temps avant de continuer à envoyer.
(...)
Pour améliorer les choses, tu peux essayer d'augmenter les tailles des
fenêtres TCP sur les machines (la source et la destination de la session
FTP, les machines intermédiaires n'ont pas d'importance). Si tu nous dis
le type de machine, on pourra (peut-être) te dire comment faire.

Pour mes tests de transfert FTP actuels, j utilise un linux sur chaque
intranet. Il s agit d'une Suse 8.0 classique.
Je compte ensuite faire la meme chose avec des Win2000 .

Comme je l'ai cité précédemment, les buts de ce vpn sont le "Browse HTML"
(site Intranet) , partage de Documents en SMB , oracle , ftp bien sur , et
un peu d'admin en telnet (incontournable)
Rencontrerai-je le meme type de soucis ?

Pour info, le satellite sur une extremité est bien évidemment indispensable
vu la region. L'offre choisie est Aramiska pour ne pas la citer :o)



Merci beaucoup de votre aide.

Bonjour,

[J'essaie d'expliquer le comportement de TCP, assez succintement. La
meilleure référence dans ce cas-là reste le volume 1 de Stevens. J'ai
peut-être considéré à tort que certains des mécanismes évoqués étaient
connus du lecteur. Si des passages sont par conséquence obscures,
n'hésitez pas à poser des questions.]

Le problème vient du "windowing": quand une machine envoie des données en
TCP à une autre, elle attend un acquittement avant de continuer (pour
éviter de tout déverser dans un trou noir pour rien). Pour éviter le genre
"j'envoie un paquet, j'attends la réponse, j'envoie un autre paquet,
j'attends la réponse...", qui serait *très* lent (voir notre bon vieil ami
Kermit pour ceux qui étaient déjà nés), TCP envoie des paquets à
concurrence de la taille de la "fenêtre" sans attendre d'acquittement.
Mais il ne continuera à envoyer (au delà de la taille de la fenêtre)
qu'une fois qu'il aura commencé à recevoir les acquittements pour les
premiers paquets. En gros, il n'y a jamais plus que la taille de la
fenêtre de paquets envoyés et pas encore acquittés.

Donc si les acquittements mettent du temps à revenir, l'émetteur peut
attendre pas mal de temps avant de continuer à envoyer.

C'est plus ou moins vrai... En fait, TCP a l'immense avantage d'être un
protocole à taille de fenêtre variable. La valeur de la fenêtre va
augmenter rapidement au début de la connexion (phase dite de "slow
start" paradoxalement) en étant incrémenté pour chaque acquittement
reçu (la fenêtre double après chaque envoi d'une fenêtre). On estime
alors que l'émetteur teste la qualité de la liaison. Une fois arrivé à
une valeur limite ("slow start threshold"), l'émetteur augmente sa
fenêtre seulement d'un paquet par fenêtre émise correctement (phase de
"congestion avoidance") : on estime qu'une limite a été atteinte et que
la congestion est proche.

Dès la première perte (détecté par une succession de trois acks
dupliqués), la valeur de la fenêtre est divisée par deux et l'émetteur
recommence à l'augmenter comme en phase de "congestion avoidance". Le
"ssthresh" est également diminué de moitié (il reflète la valeur d'une
demi-fenêtre de congestion lors de la dernière congestion). Le
comportement est différent en cas de timeout (pas d'acquittement
pendant un temps dépendant du RTT) : le ssthresh est bien divisé par
deux mais la fenêtre de congestion repart de zéro en phase de "slow
start" (augmentation exponentielle).

La taille de la fenêtre peut varier pas mal d'une machine à l'autre (OS,
config...). On voit aussi bien 8K que 64K, par exemple. Et avec 8K, et une
latence de l'ordre de 500 ms, on ne dépasse pas 16 Ko/seconde.

Ca, en revanche, c'est faux : la valeur de la fenêtre n'est pas
accessible à l'utilisateur et elle va de toute façon évoluée au cours
de la connexion. Le seul paramètre accessible est la valeur des buffers
en émission et en réception (valeur par défaut et maximale) : ces
valeurs influent sur les valeurs initiales des paramètres de TCP ainsi
que sur la taille de la fenêtre du récepteur.

Pour améliorer les choses, tu peux essayer d'augmenter les tailles des
fenêtres TCP sur les machines (la source et la destination de la session
FTP, les machines intermédiaires n'ont pas d'importance). Si tu nous dis
le type de machine, on pourra (peut-être) te dire comment faire.

C'est en effet une bonne idée d'augmenter la taille des *sockets
buffers* (pas de la fenêtre de congestion). Cela va faciliter les
retransmissions : c'est en effet dans ces buffers que sont stockés
d'une part sur l'émetteur les paquets non encore acquittés, et d'autre
par sur le récepteur les paquets reçus non encore traités par
l'application.

Typiquement, une bonne valeur pour ces buffers est d'utiliser la valeur
du produit débit x délai AR. Par exemple, sur des expériences que je
pratique sur une liaison à plus d'un gigabit/s et presque 200ms de RTT,
j'utilise des sockets buffers de 256Mbit. Dans ton cas, une bonne
valeur peut être (délai de l'ordre de la seconde par satellite) :
64 ko/s * ~2s = 128ko. La valeur par défaut est souvent 64ko : à
vérifier donc... Pour t'aider à changer cette valeur, il faudrait que
tu nous donnes plus de détails.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle>

Bonjour,

[J'essaie d'expliquer le comportement de TCP, assez succintement. La
meilleure référence dans ce cas-là reste le volume 1 de Stevens. J'ai
peut-être considéré à tort que certains des mécanismes évoqués étaient
connus du lecteur. Si des passages sont par conséquence obscurs,
n'hésitez pas à poser des questions.]

Le problème vient du "windowing": quand une machine envoie des données en
TCP à une autre, elle attend un acquittement avant de continuer (pour
éviter de tout déverser dans un trou noir pour rien). Pour éviter le genre
"j'envoie un paquet, j'attends la réponse, j'envoie un autre paquet,
j'attends la réponse...", qui serait *très* lent (voir notre bon vieil ami
Kermit pour ceux qui étaient déjà nés), TCP envoie des paquets à
concurrence de la taille de la "fenêtre" sans attendre d'acquittement.
Mais il ne continuera à envoyer (au delà de la taille de la fenêtre)
qu'une fois qu'il aura commencé à recevoir les acquittements pour les
premiers paquets. En gros, il n'y a jamais plus que la taille de la
fenêtre de paquets envoyés et pas encore acquittés.

Donc si les acquittements mettent du temps à revenir, l'émetteur peut
attendre pas mal de temps avant de continuer à envoyer.

C'est plus ou moins vrai... En fait, TCP a l'immense avantage d'être un
protocole à taille de fenêtre variable. La valeur de la fenêtre va
augmenter rapidement au début de la connexion (phase dite de "slow
start" paradoxalement) en étant incrémenté pour chaque acquittement
reçu (la fenêtre double après chaque envoi d'une fenêtre). On estime
alors que l'émetteur teste la qualité de la liaison. Une fois arrivé à
une valeur limite ("slow start threshold"), l'émetteur augmente sa
fenêtre seulement d'un paquet par fenêtre émise correctement (phase de
"congestion avoidance") : on estime qu'une limite a été atteinte et que
la congestion est proche.

Dès la première perte (détecté par une succession de trois acks
dupliqués), la valeur de la fenêtre est divisée par deux et l'émetteur
recommence à l'augmenter comme en phase de "congestion avoidance". Le
"ssthresh" est également diminué de moitié (il reflète la valeur d'une
demi-fenêtre de congestion lors de la dernière congestion). Le
comportement est différent en cas de timeout (pas d'acquittement
pendant un temps dépendant du RTT) : le ssthresh est bien divisé par
deux mais la fenêtre de congestion repart de zéro en phase de "slow
start" (augmentation exponentielle).

La taille de la fenêtre peut varier pas mal d'une machine à l'autre (OS,
config...). On voit aussi bien 8K que 64K, par exemple. Et avec 8K, et une
latence de l'ordre de 500 ms, on ne dépasse pas 16 Ko/seconde.

Ca, en revanche, c'est faux : la valeur de la fenêtre n'est pas
accessible à l'utilisateur et elle va de toute façon évoluée au cours
de la connexion. Le seul paramètre accessible est la valeur des buffers
en émission et en réception (valeur par défaut et maximale) : ces
valeurs influent sur les valeurs initiales des paramètres de TCP ainsi
que sur la taille de la fenêtre du récepteur.

Pour améliorer les choses, tu peux essayer d'augmenter les tailles des
fenêtres TCP sur les machines (la source et la destination de la session
FTP, les machines intermédiaires n'ont pas d'importance). Si tu nous dis
le type de machine, on pourra (peut-être) te dire comment faire.

C'est en effet une bonne idée d'augmenter la taille des *sockets
buffers* (pas de la fenêtre de congestion). Cela va faciliter les
retransmissions : c'est en effet dans ces buffers que sont stockés
d'une part sur l'émetteur les paquets non encore acquittés, et d'autre
par sur le récepteur les paquets reçus non encore traités par
l'application.

Typiquement, une bonne valeur pour ces buffers est d'utiliser la valeur
du produit débit x délai AR. Par exemple, sur des expériences que je
pratique sur une liaison à plus d'un gigabit/s et presque 200ms de RTT,
j'utilise des sockets buffers de 256Mbit. Dans ton cas, une bonne
valeur peut être (délai de l'ordre de la seconde par satellite) :
64 ko/s * ~2s = 128ko. La valeur par défaut est souvent 64ko : à
vérifier donc... Pour t'aider à changer cette valeur, il faudrait que
tu nous donnes plus de détails.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle>

On Fri, 3 Oct 2003 14:42:42 +0200, Bill <g.corbehem@wanadoo.fr> wrote:

Tout a fait , oui :o)
Le but principal de ce VPN , sera de la connexion HTTP , partage SMB ,
connexion Oracle , et autres transferts FTP

Par contre , en attendant, je configure le systeme a distance (plus de
450
km de distance).... ce qui implique du telnet.....et la.... la latence
propre au satellite se fait cruellement sentir :o(

Plutôt 72000 km :-)

Pour mes tests de transfert FTP actuels, j utilise un linux sur chaque
intranet. Il s agit d'une Suse 8.0 classique.

Ben tu peux commencer par regarder un petit sysctl sur
net.ipv4.tcp_{rmem,wmem,mem} si je ne m'abuse. Cf man tcp pour les détails.

Je compte ensuite faire la meme chose avec des Win2000 .

Là je sais pas trop comment ça se règle. Probablement quelque chose dans
la base de registres.

Comme je l'ai cité précédemment, les buts de ce vpn sont le "Browse HTML"
(site Intranet)

Mets un proxy-cache ou un miroir en local, ça aidera énormément.

partage de Documents en SMB

Urg.

oracle , ftp bien sur , et
un peu d'admin en telnet (incontournable)
Rencontrerai-je le meme type de soucis ?

Voire pire. Les protocoles qui font beaucoup de tous petits échanges (soit
de l'UDP, soit tout plein de petites sessions TCP) sont très largement
handicapées par la latence. Le problème ne sera pas le même (pas de
problème de windowing: il n'y en a pas!), mais l'effet sera nettement pire.

Suivant les protocoles, les applications exactes, les flux entre les
différents sites, etc, mettre un miroir ou un cache pourrait être très
utile. Dans certains cas, un changement de protocole n'est pas forcément
une mauvaise idée, quand c'est possible, bien sûr.

Pour info, le satellite sur une extremité est bien évidemment
indispensable
vu la region.

Et une voie de retour terrestre, voire un mix satellite/terrestre (les
gros paquets par le satellite, les petits par le terrestre), ce n'est pas
envisageable?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Pour mes tests de transfert FTP actuels, j utilise un linux sur chaque
intranet. Il s agit d'une Suse 8.0 classique.

Ben tu peux commencer par regarder un petit sysctl sur
net.ipv4.tcp_{rmem,wmem,mem} si je ne m'abuse. Cf man tcp pour les
détails.

ok je jetterai un coup d oeil.

Comme je l'ai cité précédemment, les buts de ce vpn sont le "Browse
HTML"

(site Intranet)

Mets un proxy-cache ou un miroir en local, ça aidera énormément.

Il s'agit d'un site intranet (localisé sur le siege associé au Satellite)
centralisant des informations et permettant surtout des ajouts et des modifs
de documents et autres par les personnes concernées des sites distants (vpn)
Le proxy-cache ou un miroir en local reste-t-il encore d actualité ?

partage de Documents en SMB

Urg.

Y a t il une bonne alternative pour avoir des meilleurs resultats vu le
context Satellite ?

oracle , ftp bien sur , et
un peu d'admin en telnet (incontournable)
Rencontrerai-je le meme type de soucis ?

Voire pire. Les protocoles qui font beaucoup de tous petits échanges (soit
de l'UDP, soit tout plein de petites sessions TCP) sont très largement
handicapées par la latence. Le problème ne sera pas le même (pas de
problème de windowing: il n'y en a pas!), mais l'effet sera nettement
pire.

Suivant les protocoles, les applications exactes, les flux entre les
différents sites, etc, mettre un miroir ou un cache pourrait être très
utile. Dans certains cas, un changement de protocole n'est pas forcément
une mauvaise idée, quand c'est possible, bien sûr.

aie aie........ autant dire alors que le VPN et le Satellite ne font pas
bon ménage du tout non ? :-(
C'est pourtant la seul solution qui s offrent a nous, malheureusement.....

Et une voie de retour terrestre, voire un mix satellite/terrestre (les
gros paquets par le satellite, les petits par le terrestre), ce n'est pas
envisageable?

Nous avons choisi le satellite car les frais France Telecom devenaient trop
consequent.....
Envisager un retour terrestre ne serait il pas un retour en arriere ?
J'avoue ne pas etre trop informé par ce type de solution...

ta boite noir c le proxy d'aramiska ?
Si c'est le cas je pense que tu peux abandonner toute idée de vpn

"Bill" <g.corbehem@wanadoo.fr> a écrit dans le message de
news:bljio4$tmc$1@news-reader2.wanadoo.fr...

Bonjour a tous,

j'ai du mal a comprendre ceci.

J'ai un VPN entre 2 reseau distant. (IPSEC FreeS/WAN )
L'un est derriere une passerelle sous Linux directement connectée a
internet.
L'autre est derriere une passerelle Linux, elle meme derriere une boite
noire connectée au satellite. Le satellite assure un download et un upload
plutot impressionnant.

Le souci est le suivant, si j'ouvre une session FTP entre une machine de
l'intranet 1 et une autre de l intranet 2 , je monte a peine a 10-15
Ko/s

(en download)
Je suis logiquement censé atteindre 64 Ko/S max (ADSL pack wanadoo 1 sur
la passerelle)

Ce qui est encore plus drole, c'est que si j ouvre 2 session FTP en
parallele, j'ai a peu pres 2 fois 10-15 Ko/S , ce qui prouvre que le
satellite en a encore sous le capot :o)


Bref j'ai du mal a comprendre...


Merci a ceux qui pourront m eclairer :o)

Salut,

On Fri, 3 Oct 2003 15:59:50 +0200, Bill <g.corbehem@wanadoo.fr> wrote:

Il s'agit d'un site intranet (localisé sur le siege associé au Satellite)
centralisant des informations et permettant surtout des ajouts et des
modifs
de documents et autres par les personnes concernées des sites distants
(vpn)
Le proxy-cache ou un miroir en local reste-t-il encore d actualité ?

Très difficile à dire sans connaître l'application exacte et les
différents flux. Evidemment, si rien n'est "cachable", ce ne sera pas très
utile. Une copie du site en local avec une base de donnée répliquée en
local aussi peut être une meilleure solution. Mais ce n'est plus vraiment
trivial, évidemment.

partage de Documents en SMB

Urg.

Y a t il une bonne alternative pour avoir des meilleurs resultats vu le
context Satellite ?

Encore une fois, ça dépend des flux, de la fréquence de mise à jour et de
consultation et par qui, etc. Dans certaines conditions, un miroir avec
une bonne synchronisation entre les deux sites peut être une bonne
solution.

aie aie........ autant dire alors que le VPN et le Satellite ne font pas
bon ménage du tout non ? :-(

Cha dépend des applications, etc. :-) Disons qu'il ne faut pas s'attendre
à ce que ça soit "comme si c'était en local", alors qu'avec un VPN
"terrestre", dans de nombreux cas, on ne s'en rend pas compte.

Nous avons choisi le satellite car les frais France Telecom devenaient
trop
consequent.....
Envisager un retour terrestre ne serait il pas un retour en arriere ?

Quand je disais "un retour terrestre", c'était une voie de retour. Genre
satellite dans un sens, terrestre dans l'autre. Mais comme d'habitude (bis
repetita), ça dépend des applications et des flux: si c'est beaucoup de
consultation depuis le site satellite, alors les flux devraient être
asymétriques, et une liaison terrestre même à un débit relativement faible
devrait suffire, et permettre de diviser par deux la latence!

Sinon, le "mix" terrestre/satellite (petits paquets d'un côté, gros de
l'autre) peut aussi être une bonne solution: une petite liaison pas trop
chère pour les premiers, et une grosse liaison pour le reste. Sachant que
ce sont les plus petits paquets qui ont le plus à souffrir de la latence,
c'est généralement une bonne option. Mais évidemment il faut commencer à
faire du routage un peu rigolo :-)

Jacques/
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

"Hellmer" <hellmer@free.fr> a écrit dans le message de
news:3f7d9697$0$27027$626a54ce@news.free.fr...

ta boite noir c le proxy d'aramiska ?
Si c'est le cas je pense que tu peux abandonner toute idée de vpn

Ca l'est :o). Elle joue surtout le role de passerelle Firewall.

Pourquoi devrai je abandonner ?