VPN => Discussion démarrée par: nvivo le 24 juillet 2011 à 22:56:49 VPN => Discussion démarrée par: nvivo le 24 juillet 2011 à 22:56:49Pourquoi prendre deux SDSL, à part pour compliquer les choses?OVH débute dans le SDSL. OVH ne propose d'agrégation de lignes SDSL que sur les NRA où il est en dégroupage! C'est à dire quelques NRA de l'agglomération de Lille. Et dans les 12 mois qui suivent, OVH prévoit de dégrouper que quelques grosses agglomérations: Paris, Bordeaux, Lyon, Marseille, et c'est tout!
Prends un FAI qui fait de l'agrégation de liens (p.ex. OVH).
Je suis si impatient car nous somme 5 à bosser sur des projets audio... les projets à envoyer aux clients font entre 5 et 15 Gb en moyenne; A l' heure actuelle nous perdons un temps fou (et donc de l'argent ) en upload. J'avoue qu'il y a aussi une part de Geek en moi mais l’intérêt principal est professionnel.
Donc pas de SDSL pour du DUAL Wan si je comprend bien ?Tu fais bien comme tu veux!
Avec une Freebox en mode bridge, on est connecté directement en Ethernet au DSLAM.Non.
+ compression des entêtes possible, voir du flux complet si lien sans pertes
Un intérêt du VPN est aussi (à rajouter à la longue liste de corretor) de pouvoir compresser.C'était quel type de VPN?
J'étais étonné quand j'ai fait un test IPERF chez un copain qui avait un VPN : 5 Mb/s en upload en ADSL ! (en même temps iperf rempli les paquets de 000000000000000000 donc facile à compresser)
La Freebox n'est pas pont Ethernet.Tu peux nous en dire plus, stp, corrector? (ou quelqu'un d'autre)
A quoi correspond ce mode bridge de la freebox?Définition du "mode bridge" : Le PC connecté à la Freebox reçoit l'IPv4 publique.
Avec TCP, dés qu'un paquet arrive après le suivant, il y a une demande de ré-émission du paquet qui arrivera en retard (les DUP ACK). Donc on peut se retrouver dans une situation ou la moitié des paquets sont ré-émis.Ce n'est pas ce que je comprends de la RFC 5681 - TCP Congestion Control (http://tools.ietf.org/html/rfc5681) (September 2009) :
3.2. Fast Retransmit/Fast Recovery (http://tools.ietf.org/html/rfc5681#section-3.2)Un DUP ACK n'est pas une demande de quoi que ce soit, c'est un signalement :
A TCP receiver SHOULD send an immediate duplicate ACK when an out-
of-order segment arrives. The purpose of this ACK is to inform the
sender that a segment was received out-of-order and which sequence
number is expected. From the sender's perspective, duplicate ACKs
can be caused by a number of network problems. First, they can be
caused by dropped segments. In this case, all segments after the
dropped segment will trigger duplicate ACKs until the loss is
repaired. Second, duplicate ACKs can be caused by the re-ordering of
data segments by the network (not a rare event along some network
paths [Pax97]). Finally, duplicate ACKs can be caused by replication
of ACK or data segments by the network. In addition, a TCP receiver
SHOULD send an immediate ACK when the incoming segment fills in all
or part of a gap in the sequence space. This will generate more
timely information for a sender recovering from a loss through a
retransmission timeout, a fast retransmit, or an advanced loss
recovery algorithm, as outlined in section 4.3.
The TCP sender SHOULD use the "fast retransmit" algorithm to detect
and repair loss, based on incoming duplicate ACKs. The fast
retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined
in section 2, without any intervening ACKs which move SND.UNA) as an
indication that a segment has been lost. After receiving 3 duplicate
ACKs, TCP performs a retransmission of what appears to be the missing
segment, without waiting for the retransmission timer to expire.
After the fast retransmit algorithm sends what appears to be the
missing segment, the "fast recovery" algorithm governs the
transmission of new data until a non-duplicate ACK arrives. The
reason for not performing slow start is that the receipt of the
duplicate ACKs not only indicates that a segment has been lost, but
also that segments are most likely leaving the network (although a
massive segment duplication by the network can invalidate this
conclusion). In other words, since the receiver can only generate a
duplicate ACK when a segment has arrived, that segment has left the
network and is in the receiver's buffer, so we know it is no longer
consuming network resources. Furthermore, since the ACK "clock"
[Jac88] is preserved, the TCP sender can continue to transmit new
segments (although transmission must continue using a reduced cwnd,
since loss is an indication of congestion).
Définition du "mode bridge" : [...]Merci beaucoup corrector, pour cette description détaillée. C'est très clair.
Ne peut-on pas envoyer des paquets avec une autre IP du même sous-réseau en mode bridge?Et si oui, est-ce que tu vas faire ce genre de choses?
Bon, j'ai fait quelques bidouilles ce soir entre ma connexion ADSL Free et un 2ieme PC derrière un modem 56k (on fait ce qu'on peut).Petite objection : là on ne sait pas si la Freebox bloque ou si c'est après. (Moi je n'ai plus de simple modem ADSL, je ne peux pas tester sans la Freebox v5.)
Bilan: même bien configuré en mode bridge, on ne peut pas faire sortir vers Internet des paquets IP ayant une IP source différente de sa propre connexion ADSL. Ca à la freebox, mais pas jusqu'au PC d'en face. Tant pis. Au moins, j'aurais essayé.
Avec TCP, dés qu'un paquet arrive après le suivant, il y a une demande de ré-émission du paquet qui arrivera en retard (les DUP ACK). Donc on peut se retrouver dans une situation ou la moitié des paquets sont ré-émis.Je suis très surpris par ça. J'avais compris qu'un des principe même des protocoles d'Internet était d'être robuste à ce genre de choses. D'être robuste à des paquets qui empruntent des chemins différents. D'être robuste à des paquets reçus dans un ordre différent. Typiquement, si un opérateur fait du load-balancing entre 2 liaisons inter-continentales, qui elles-mêmes ont des délais légèrement différents, l'ordre des paquets n'est absolument pas garantit. Je me trompe?
alias bond0 bonding
options bonding mode=4 xmit_hash_policy=layer3+4 miimon=100 downdelay=200 updelay=200
Une certitude : des le premier paquet perdu il y a envoi d'un DUP ACK et ensuite à chaque paquet reçu il va envoyer un DUP ACK (alors que normalement TCP n'acquitte qu'un paquet sur deux)Vivien, en relisant ce que cite corrector, je comprend qu'il n'y a de répétition de paquet à priori perdu que si l'èmetteur reçoit 3 d-Ack qui lui font comprendre qu'au moins un paquet a été perdu. Donc OK pour le d-ack dès le premier paquet mal ordonné, mais pas OK pour la ré-émission immédiate.
Je vais vérifier si l'èmetteur ré-èmet immédiatement le paquet perdu (de mémoire c'est oui, mais je préfère vérifier)
TCP est robuste (le trafic passe toujours quel que soit les problèmes rencontrés) mais en cas de problèmes, le débit diminue. Je pense que dans le cas décrit le débit va diminuer jusqu'à faire que la gigue soit suffisamment faible pour que les paquets soit dans l'ordre.Si c'est vraiment comme ça, c'est pas terrible, TCP-IP. Je pensais que c'était plus élaboré.