Auteur Sujet: Vrai 1Gbps sur Freebox v6 ? (Lu 73000 fois)

corrector · « **Réponse #132 le:** 06 décembre 2015 à 09:55:55 »

2. Protocol overview

In this memo, we describe a technique for using the Don't Fragment
(DF) bit in the IP header to dynamically discover the PMTU of a path.
The basic idea is that a source host initially assumes that the PMTU
of a path is the (known) MTU of its first hop, and sends all
datagrams on that path with the DF bit set. If any of the datagrams
are too large to be forwarded without fragmentation by some router
along the path, that router will discard them and return ICMP
Destination Unreachable messages with a code meaning "fragmentation
needed and DF set" [7]. Upon receipt of such a message (henceforth
called a "Datagram Too Big" message), the source host reduces its
assumed PMTU for the path.

La RFC 1191 date de 1990!

kgersen · « **Réponse #133 le:** 06 décembre 2015 à 10:01:20 »

Citation de: vivien le 06 décembre 2015 à 09:41:55

Effectivement, il serait intéressant de savoir comment Google détermine la MTU maximum dans son protocole QUIC (Quick UDP Internet Connections) qui remplace TCP dans Chrome pour certains services Google.
J'imagine que Chrome fait une connexion TCP pour récupérer le MTU via la MSS transmis le paquet [SYN-ACK] du serveur et éventuellement modifié par le réseau pour diminuer la MTU.

Dixit la doc mais elle n'est peut-etre pas a jour le découverte de MTU dans QUIC est en chantier donc pour le moment c'est un MTU max a 1350 en IPv6 et 1370 en IPv4.

corrector · « **Réponse #134 le:** 06 décembre 2015 à 10:10:26 »

man ip(7)

IP_MTU (since Linux 2.2)
Retrieve the current known path MTU of the current socket.
Returns an integer.

IP_MTU is valid only for getsockopt(2) and can be employed
only when the socket has been connected.

IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket.
When enabled, Linux will perform Path MTU Discovery as defined
in RFC 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM
sockets, IP_PMTUDISC_DO forces the don't-fragment flag to be
set on all outgoing packets. It is the user's responsibility
to packetize the data in MTU-sized chunks and to do the
retransmits if necessary. The kernel will reject (with
EMSGSIZE) datagrams that are bigger than the known path MTU.
IP_PMTUDISC_WANT will fragment a datagram if needed according
to the path MTU, or will set the don't-fragment flag
otherwise.

The system-wide default can be toggled between
IP_PMTUDISC_WANT and IP_PMTUDISC_DONT by writing
(respectively, zero and nonzero values) to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.

Path MTU discovery value Meaning
IP_PMTUDISC_WANT Use per-route settings.
IP_PMTUDISC_DONT Never do Path MTU Discovery.
IP_PMTUDISC_DO Always do Path MTU Discovery.
IP_PMTUDISC_PROBE Set DF but ignore Path MTU.

When PMTU discovery is enabled, the kernel automatically keeps
track of the path MTU per destination host. When it is
connected to a specific peer with connect(2), the currently
known path MTU can be retrieved conveniently using the IP_MTU
socket option (e.g., after an EMSGSIZE error occurred). The
path MTU may change over time. For connectionless sockets
with many destinations, the new MTU for a given destination
can also be accessed using the error queue (see IP_RECVERR).
A new error will be queued for every incoming MTU update.

While MTU discovery is in progress, initial packets from
datagram sockets may be dropped. Applications using UDP
should be aware of this and not take it into account for their
packet retransmit strategy.

To bootstrap the path MTU discovery process on unconnected
sockets, it is possible to start with a big datagram size (up
to 64K-headers bytes long) and let it shrink by updates of the
path MTU.

To get an initial estimate of the path MTU, connect a datagram
socket to the destination address using connect(2) and
retrieve the MTU by calling getsockopt(2) with the IP_MTU
option.

It is possible to implement RFC 4821 MTU probing with
SOCK_DGRAM or SOCK_RAW sockets by setting a value of
IP_PMTUDISC_PROBE (available since Linux 2.6.22). This is
also particularly useful for diagnostic tools such as
tracepath( 8 ) that wish to deliberately send probe packets
larger than the observed Path MTU.

Marco POLO · « **Réponse #135 le:** 06 décembre 2015 à 22:26:00 »

Citation de: Nico le 03 décembre 2015 à 17:37:32

Ceci étant dit, plein de définitions sur ces deux articles :

https://lafibre.info/raccordement-immeuble/lexique/

https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/

J'ai retrouvé, au fin fond de mes marque-pages, des sites assez complets donnant la définition de la plupart des acronymes utilisés en informatique:
Le premier sur le site de WikiPédia/WikiWand, et
Le Jargon Français.
Pour ceux que ça intéresse...

underground78 · « **Réponse #136 le:** 03 février 2016 à 20:32:06 »

Attention si vous testez les débits de votre réseau local en utilisant votre Freebox comme serveur local. Depuis la dernière mise à jour Free offre la possibilité de se connecter de façon sécurisée à la box, ce qui est très bien mais qui a un impact monstrueux sur les débits.

Visiblement un bug empêche de se connecter à la Freebox en FTP non sécurisé depuis cette mise à jour et je suis coincé autour de 5 Mo/s alors que j'étais plutôt à 45 Mo/s avant (limité par le disque dur).

Peut-être que mbizon pourra nous dire s'il reste des optimisations à faire ou si on est déjà au taquet.

alain_p · « **Réponse #137 le:** 03 février 2016 à 21:58:20 »

Je pense que tu parles de la mise à jour à la 3.3, et son support de let's encrypt ? Oui, il est connu que le cryptage peut être lourd pour le processeur, et faire baisser les débits. Je l'avais constaté avec un boîtier VPN.

Je viens d'ailleurs de faire cette mise à jour, et d'activer le domaine et la demande de certificat. Je n'ai pas encore fait de test de débit interne sur le LAN.

underground78 · « **Réponse #138 le:** 03 février 2016 à 22:02:23 »

Le seul vrai problème (que j'ai déjà rapporté sur le bug tracker) c'est qu'on ne puisse plus se connecter en FTP non sécurisé. Pour le débit ça me parait pas anormal même si la baisse est drastique.

Darklight · « **Réponse #139 le:** 03 février 2016 à 22:04:34 »

Citation de: Marco POLO le 06 décembre 2015 à 22:26:00

J'ai retrouvé, au fin fond de mes marque-pages, des sites assez complets donnant la définition de la plupart des acronymes utilisés en informatique:
Le premier sur le site de WikiPédia/WikiWand, et
Le Jargon Français.
Pour ceux que ça intéresse...

Merci, c'est dans mes marque-pages également!

kgersen · « **Réponse #140 le:** 03 février 2016 à 22:22:24 »

Citation de: alain_p le 03 février 2016 à 21:58:20

Je pense que tu parles de la mise à jour à la 3.3, et son support de let's encrypt ? Oui, il est connu que le cryptage peut être lourd pour le processeur, et faire baisser les débits. Je l'avais constaté avec un boîtier VPN.

Je viens d'ailleurs de faire cette mise à jour, et d'activer le domaine et la demande de certificat. Je n'ai pas encore fait de test de débit interne sur le LAN.

Pourtant le CPU de la V6 (Kirkwood 88F6281) supporte l'acceleration matérielle pour le chiffrement (demontrer ici avec SSL a l'époque). Free ne l'a peut-etre pas utilisé ?

underground78 · « **Réponse #141 le:** 03 février 2016 à 22:28:31 »

Ouaip, c'est ce que j'espérais apprendre de Maxime Bizon. Ça me parait pas impossible qu'ils aient choisi une implèmentation complètement logicielle pour une première version.

alain_p · « **Réponse #142 le:** 03 février 2016 à 22:46:18 »

Citation de: kgersen le 03 février 2016 à 22:22:24

Pourtant le CPU de la V6 (Kirkwood 88F6281) supporte l'acceleration matérielle pour le chiffrement (demontrer ici avec SSL a l'époque). Free ne l'a peut-etre pas utilisé ?

Je viens de regarder le lien, cela ne semble pas tout à fait direct, et c'est peut-être pourquoi cela n'a pas encore été implèmenté. Maxime Bizon ignore peut-être cette possibilité ?

Citer

The reason kernel patches are required is because acceleration depends on the BSD style cryptodev kernel interface. There is an alternative, more up to date project that provides this much less intrusively: Cryptodev-linux. It provides a standalone driver that doesn’t require the entire kernel to be recompiled for it, and it works with the 2.6.36+ kernels.

mbizon · « **Réponse #143 le:** 04 février 2016 à 09:34:49 »

Citation de: underground78 le 03 février 2016 à 20:32:06

Attention si vous testez les débits de votre réseau local en utilisant votre Freebox comme serveur local. Depuis la dernière mise à jour Free offre la possibilité de se connecter de façon sécurisée à la box, ce qui est très bien mais qui a un impact monstrueux sur les débits.

Visiblement un bug empêche de se connecter à la Freebox en FTP non sécurisé depuis cette mise à jour et je suis coincé autour de 5 Mo/s alors que j'étais plutôt à 45 Mo/s avant (limité par le disque dur).

désolé, on regarde pour corriger dans la prochaine version

Citation de: underground78 le 03 février 2016 à 20:32:06

Peut-être que mbizon pourra nous dire s'il reste des optimisations à faire ou si on est déjà au taquet.

le bloc hardware n'est pas (encore) utilisé

Auteur Sujet: Vrai 1Gbps sur Freebox v6 ? (Lu 73000 fois)

corrector

corrector