Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

STP ne me fais pas dire des choses que je n ai pas dites. Merci :)

Sent from my iPad

On 22 Dec 2012, at 21:25, Sylvain Vallerot  wrote:

> 
> 
> On 21/12/2012 12:06, Thomas Mangin wrote:
>> Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
>> de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
>> Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
>> du temps et le DPI est utilisé pour faire passer en priorité les protocoles
>> temps réels ou importants ( voip, email , ... ).
>> Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la 
>> poubelle
>> le plus rapidement et rempli ce qui n'est pas utilisé par les autres 
>> protocoles.
> 
> Beaux exemples de ce qui se passe quand on abdique la neutralité du net,

ici

> des choix dictés par le marketing et par la déformation des usages :
> - assimiler le mail à un protocole temps réel

ici

> - défavoriser le pair à pair
> - favoriser les communications centralisées

ici

> - des tuyaux remplis à 100%
> 
> Carton plein : tout dans le mille.
> 
>> Il semblerait que LEDBAT offre une solution intéressante et moins chère au
>> même problème de gestion de capacité ... mais avec moins de contrôle pour
>> le FAI.
> 
> s/FAI/commerciaux/
> 
> J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
> sont déjà tous sous surveillance pour des raisons strictement commerciales.

et la

> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Sylvain Vallerot]

On 21/12/2012 12:06, Thomas Mangin wrote:

Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
du temps et le DPI est utilisé pour faire passer en priorité les protocoles
temps réels ou importants ( voip, email , ... ).
Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la poubelle
le plus rapidement et rempli ce qui n'est pas utilisé par les autres protocoles.


Beaux exemples de ce qui se passe quand on abdique la neutralité du net,
des choix dictés par le marketing et par la déformation des usages :
- assimiler le mail à un protocole temps réel
- défavoriser le pair à pair
- favoriser les communications centralisées
- des tuyaux remplis à 100%

Carton plein : tout dans le mille.


Il semblerait que LEDBAT offre une solution intéressante et moins chère au
même problème de gestion de capacité ... mais avec moins de contrôle pour
le FAI.


s/FAI/commerciaux/

J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
sont déjà tous sous surveillance pour des raisons strictement commerciales.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

On 21 Dec 2012, at 14:23, Simon Perreault  wrote:

> LEDBAD est déjà massivement déployé:
> http://www.utorrent.com/intl/fr/help/documentation/utp

Comme annoncé a' la fin de l'article de Stephane, donc j'aurai du dire : 
largement déployé dans de multiples applications :)

Thomas

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Simon Perreault]

Le 2012-12-21 12:54, Thomas Mangin a écrit :

Il y a ici une solution qui va dans le bon sens et qui permet aux
utilisateurs et aux développeurs de prendre leurs responsabilités,
ce serait dommage que de telles propositions partent à la poubelle
parce que certains opérateurs se croient plus malins.
L'intelligence dans le réseau on ne peut pas dire que cela ait déjà
marché...


Je n'ai pas de boule de cristal, et je ne sais pas si LEDBAT sera
déployé massivement ou pas. Je pense que l'approche a du mérite.


LEDBAD est déjà massivement déployé:

http://www.utorrent.com/intl/fr/help/documentation/utp

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

On 21 Dec 2012, at 11:21, Emmanuel Thierry  wrote:

> Sans vouloir engager un troll pro/anti-DPI (je pense que maintenant on 
> connait les arguments de chaque partie par coeur), c'est dommage d'utiliser 
> le DPI pour ce genre d'usages.

Le DPI est cher. Comme tout investissement, tu dois trouver un retour !

> C'est ce qui pousse les développeurs à tout faire passer au dessus d'HTTP, et 
> qui va pousser bientôt à obfusquer son trafic pour le faire passer pour un 
> protocole plus priorisé. Si ça se trouve on sera bientôt obligés de déployer 
> iodine partout...

IMHO, la création de websocket est a' attribuer aux administrateurs de 
firewalls paranoïaques plus qu'aux FAI et au DPI (pas de démarrage de troll ici 
non-plus - les trolls ont le droit a des vacances pour Noel aussi).

> Il y a ici une solution qui va dans le bon sens et qui permet aux 
> utilisateurs et aux développeurs de prendre leurs responsabilités, ce serait 
> dommage que de telles propositions partent à la poubelle parce que certains 
> opérateurs se croient plus malins. L'intelligence dans le réseau on ne peut 
> pas dire que cela ait déjà marché...

Je n'ai pas de boule de cristal, et je ne sais pas si LEDBAT sera déployé 
massivement ou pas. Je pense que l'approche a du mérite.

J'ai simplement essayé d'expliquer pourquoi une réduction de prix pour 
l'utilisation de LEDBAT était a mon avis improbable.

Thomas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Emmanuel Thierry]

Sans vouloir engager un troll pro/anti-DPI (je pense que maintenant on connait 
les arguments de chaque partie par coeur), c'est dommage d'utiliser le DPI pour 
ce genre d'usages. C'est ce qui pousse les développeurs à tout faire passer au 
dessus d'HTTP, et qui va pousser bientôt à obfusquer son trafic pour le faire 
passer pour un protocole plus priorisé. Si ça se trouve on sera bientôt obligés 
de déployer iodine partout...

Il y a ici une solution qui va dans le bon sens et qui permet aux utilisateurs 
et aux développeurs de prendre leurs responsabilités, ce serait dommage que de 
telles propositions partent à la poubelle parce que certains opérateurs se 
croient plus malins. L'intelligence dans le réseau on ne peut pas dire que cela 
ait déjà marché...

Cordialement
Emmanuel Thierry


Le 21 déc. 2012 à 12:06, Thomas Mangin  a 
écrit :

> Je ne peux pas parler du marché français :-D mais ...
> 
> Sur le marché anglais les chances d'une remise sont IMHO quasi nulles. Quasi 
> tous les FAI avec plus de quelques milliers de lignes utilisateurs utilisent 
> du DPI pour réguler le trafic de leurs clients. 
> 
> Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme de 
> cloche, que l'on retrouve toujours chez les fournisseurs de transit. Depuis, 
> les lignes ont de plus en plus tendance a être utilise a' 100% 100% du temps 
> et le DPI est utilisé pour faire passer en priorité les protocoles temps 
> réels ou importants ( voip, email , ... ). Le P2P  ( qui a dit Youtube !! ?? 
> ) est ce qui passe normalement a la poubelle le plus rapidement et rempli ce 
> qui n'est pas utilisé par les autres protocoles.
> 
> Il semblerait que LEDBAT offre une solution intéressante et moins chère au 
> même problème de gestion de capacité ... mais avec moins de contrôle pour le 
> FAI.
> 
> Comme la plupart des solutions DPI peuvent être utilisées pour faire de 
> l'interception légale de trafic et comme les demandes d'interception ne 
> disparaitront pas même si tous les clients d'un FAI utilisant LEDBAT, un FAI 
> ne peut pas espérer faire des économies en remplaçant son DPI par un LEDBAT 
> cote client.
> 
> je te souhaite donc bonne chance pour obtenir cette réduction  
> Qui sait, mon analyse est peut-être totalement fausse ou le père Noel 
> écoutera peut-etre ta demande ...
> 
> Thomas
> 
> On 20 Dec 2012, at 08:42, Stephane Bortzmeyer  wrote:
> 
>> La question qui tue : qui ici est prêt à faire une réduction de tarifs
>> à ses clients pour des applications « gentilles », qui utiliseraient
>> cet algorithme LEDBAT pour ne pas charger le réseau ?
>> 
>> http://www.bortzmeyer.org/6817.html
>> 
>> 
>> 
>> Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), 
>> J. Iyengar (Franklin and Marshall College), M. Kuehlewind (University of 
>> Stuttgart)
>> 
>> 
>> 
>> 
>> 
>> 
>> Alors que tant d'efforts de recherche ont été dépensés pour faire des 
>> réseaux informatiques et des protocoles qui permettent d'aller *plus 
>> vite*, d'attendre moins longtemps avant de voir la page d'accueil de 
>> TF1, le groupe de travail LEDBAT  
>> ("Low Extra Delay Background Transport ") de l'IETF travaillait à un 
>> tout autre projet : un protocole de transport de données qui aille 
>> *moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser 
>> celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses 
>> bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un 
>> algorithme « développement durable ».
>> 
>> LEDBAT n'est donc pas un protocole complet, mais un algorithme de 
>> contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les 
>> protocoles de transport évitent de saturer le réseau. Le plus connu et 
>> le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses 
>> objectifs sont d'utiliser le réseau à fond et d'assurer une relative 
>> égalité entre les flots de données qui se concurrencent sur ce réseau. 
>> LEDBAT, au contraire, vise avant tout à *céder* la place aux autre 
>> flots, non-LEDBAT.
>> 
>> Mais pourquoi diable voudrait-on être si généreux ? Cela peut être 
>> parce qu'on estime les autres flots plus importants : si je télécharge 
>> Plus belle la vie pendant que je passe un coup de téléphone via SIP, je 
>> souhaite que le téléchargement ne prenne pas de capacité si SIP en a 
>> besoin (c'est la différence entre applications d'« arrière-plan » comme 
>> le transfert de gros fichiers et d'« avant-plan » comme un coup de 
>> téléphone ou une session SSH interactive). Ou bien cela peut être pour 
>> profiter de réductions offertes par le réseau : après tout, un routeur 
>> ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets 
>> circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il 
>> serait donc logique que les transports « charognards », comme LEDBAT, 
>> qui n'utilisent la capacité résea

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

Je ne peux pas parler du marché français :-D mais ...

Sur le marché anglais les chances d'une remise sont IMHO quasi nulles. Quasi 
tous les FAI avec plus de quelques milliers de lignes utilisateurs utilisent du 
DPI pour réguler le trafic de leurs clients. 

Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme de 
cloche, que l'on retrouve toujours chez les fournisseurs de transit. Depuis, 
les lignes ont de plus en plus tendance a être utilise a' 100% 100% du temps et 
le DPI est utilisé pour faire passer en priorité les protocoles temps réels ou 
importants ( voip, email , ... ). Le P2P  ( qui a dit Youtube !! ?? ) est ce 
qui passe normalement a la poubelle le plus rapidement et rempli ce qui n'est 
pas utilisé par les autres protocoles.

Il semblerait que LEDBAT offre une solution intéressante et moins chère au même 
problème de gestion de capacité ... mais avec moins de contrôle pour le FAI.

Comme la plupart des solutions DPI peuvent être utilisées pour faire de 
l'interception légale de trafic et comme les demandes d'interception ne 
disparaitront pas même si tous les clients d'un FAI utilisant LEDBAT, un FAI ne 
peut pas espérer faire des économies en remplaçant son DPI par un LEDBAT cote 
client.

je te souhaite donc bonne chance pour obtenir cette réduction  
Qui sait, mon analyse est peut-être totalement fausse ou le père Noel écoutera 
peut-etre ta demande ...

Thomas

On 20 Dec 2012, at 08:42, Stephane Bortzmeyer  wrote:

> La question qui tue : qui ici est prêt à faire une réduction de tarifs
> à ses clients pour des applications « gentilles », qui utiliseraient
> cet algorithme LEDBAT pour ne pas charger le réseau ?
> 
> http://www.bortzmeyer.org/6817.html
> 
> 
> 
> Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), J. 
> Iyengar (Franklin and Marshall College), M. Kuehlewind (University of 
> Stuttgart)
> 
> 
> 
> 
> 
> 
> Alors que tant d'efforts de recherche ont été dépensés pour faire des 
> réseaux informatiques et des protocoles qui permettent d'aller *plus 
> vite*, d'attendre moins longtemps avant de voir la page d'accueil de 
> TF1, le groupe de travail LEDBAT  
> ("Low Extra Delay Background Transport ") de l'IETF travaillait à un 
> tout autre projet : un protocole de transport de données qui aille 
> *moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser 
> celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses 
> bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un 
> algorithme « développement durable ».
> 
> LEDBAT n'est donc pas un protocole complet, mais un algorithme de 
> contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les 
> protocoles de transport évitent de saturer le réseau. Le plus connu et 
> le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses 
> objectifs sont d'utiliser le réseau à fond et d'assurer une relative 
> égalité entre les flots de données qui se concurrencent sur ce réseau. 
> LEDBAT, au contraire, vise avant tout à *céder* la place aux autre 
> flots, non-LEDBAT.
> 
> Mais pourquoi diable voudrait-on être si généreux ? Cela peut être 
> parce qu'on estime les autres flots plus importants : si je télécharge 
> Plus belle la vie pendant que je passe un coup de téléphone via SIP, je 
> souhaite que le téléchargement ne prenne pas de capacité si SIP en a 
> besoin (c'est la différence entre applications d'« arrière-plan » comme 
> le transfert de gros fichiers et d'« avant-plan » comme un coup de 
> téléphone ou une session SSH interactive). Ou bien cela peut être pour 
> profiter de réductions offertes par le réseau : après tout, un routeur 
> ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets 
> circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il 
> serait donc logique que les transports « charognards », comme LEDBAT, 
> qui n'utilisent la capacité réseau que lorsque personne n'en veut, 
> reçoivent une récompense financière, par exemple une réduction des prix 
> (parlez-en à votre FAI).
> 
> Pour les détails sur les motivations de LEDBAT et les raisons pour 
> lesquelles des technqiues comme le "shaping" ne conviennent pas, voir 
> le premier RFC du groupe LEDBAT, le RFC 6297. Ici, je vais me focaliser 
> sur l'algorithme spécifié par LEDBAT et qui répond au cahier des 
> charges : céder la place le plus vite possible.
> 
> Le principe de cet algorithme est simple : utiliser les variations du 
> temps de voyage des paquets pour détecter l'approche de la congestion 
> et refermer alors la fenêtre de transmission. TCP utilise 
> essentiellement le taux de pertes de paquets comme indicateur (ou les 
> marques ECN du RFC 3168). Les routeurs ayant des tampons 
> d'entrée-sortie, lorsque la ligne de sortie est saturée, les paquets 
> commencent à s'entasser dans ce tampon. Lorsqu'il est plein, le routeur 
> j

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Emmanuel Thierry]

Le 21 déc. 2012 à 11:15, Stephane Bortzmeyer  a écrit :

> On Fri, Dec 21, 2012 at 11:12:38AM +0100,
> Simon Perreault  wrote 
> a message of 21 lines which said:
> 
>> Techniquement, comment est-ce que l'ISP pourrait identifier les
>> paquets utilisant LEDBAT?
> 
> Bonne question.
> 

Cela va un peu de pair avec ConEx, non ?
En l'occurrence l'opérateur peut pénaliser les utilisateurs qui n'utilisent pas 
du LEDBAT en incrémentant leur compteur de congestion quand leurs paquets sont 
droppés.

Cordialement,
Emmanuel Thierry

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Simon Perreault]

Le 2012-12-20 09:42, Stephane Bortzmeyer a écrit :

La question qui tue : qui ici est prêt à faire une réduction de tarifs
à ses clients pour des applications « gentilles », qui utiliseraient
cet algorithme LEDBAT pour ne pas charger le réseau ?


Stéphane,

Es-tu sérieux?

Cordialement,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Stephane Bortzmeyer]

La question qui tue : qui ici est prêt à faire une réduction de tarifs
à ses clients pour des applications « gentilles », qui utiliseraient
cet algorithme LEDBAT pour ne pas charger le réseau ?

http://www.bortzmeyer.org/6817.html



Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), J. 
Iyengar (Franklin and Marshall College), M. Kuehlewind (University of Stuttgart)






Alors que tant d'efforts de recherche ont été dépensés pour faire des 
réseaux informatiques et des protocoles qui permettent d'aller *plus 
vite*, d'attendre moins longtemps avant de voir la page d'accueil de 
TF1, le groupe de travail LEDBAT  
("Low Extra Delay Background Transport ") de l'IETF travaillait à un 
tout autre projet : un protocole de transport de données qui aille 
*moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser 
celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses 
bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un 
algorithme « développement durable ».

LEDBAT n'est donc pas un protocole complet, mais un algorithme de 
contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les 
protocoles de transport évitent de saturer le réseau. Le plus connu et 
le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses 
objectifs sont d'utiliser le réseau à fond et d'assurer une relative 
égalité entre les flots de données qui se concurrencent sur ce réseau. 
LEDBAT, au contraire, vise avant tout à *céder* la place aux autre 
flots, non-LEDBAT.

Mais pourquoi diable voudrait-on être si généreux ? Cela peut être 
parce qu'on estime les autres flots plus importants : si je télécharge 
Plus belle la vie pendant que je passe un coup de téléphone via SIP, je 
souhaite que le téléchargement ne prenne pas de capacité si SIP en a 
besoin (c'est la différence entre applications d'« arrière-plan » comme 
le transfert de gros fichiers et d'« avant-plan » comme un coup de 
téléphone ou une session SSH interactive). Ou bien cela peut être pour 
profiter de réductions offertes par le réseau : après tout, un routeur 
ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets 
circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il 
serait donc logique que les transports « charognards », comme LEDBAT, 
qui n'utilisent la capacité réseau que lorsque personne n'en veut, 
reçoivent une récompense financière, par exemple une réduction des prix 
(parlez-en à votre FAI).

Pour les détails sur les motivations de LEDBAT et les raisons pour 
lesquelles des technqiues comme le "shaping" ne conviennent pas, voir 
le premier RFC du groupe LEDBAT, le RFC 6297. Ici, je vais me focaliser 
sur l'algorithme spécifié par LEDBAT et qui répond au cahier des 
charges : céder la place le plus vite possible.

Le principe de cet algorithme est simple : utiliser les variations du 
temps de voyage des paquets pour détecter l'approche de la congestion 
et refermer alors la fenêtre de transmission. TCP utilise 
essentiellement le taux de pertes de paquets comme indicateur (ou les 
marques ECN du RFC 3168). Les routeurs ayant des tampons 
d'entrée-sortie, lorsque la ligne de sortie est saturée, les paquets 
commencent à s'entasser dans ce tampon. Lorsqu'il est plein, le routeur 
jette des paquets (et TCP va alors réagir). On voit que l'augmentation 
du temps de voyage (dû au séjour dans le tampon) *précède* la perte de 
paquets. En réagissant dès cette augmentation, LEDBAT atteint son 
objectif de céder la place à TCP. (À noter qu'il existe des variantes 
de TCP qui utilisent également le temps de voyage comme indicateur de 
l'approche de la congestion, par exemple TCP Vegas, documenté dans 
« "TCP Vegas: New techniques for congestion detection and avoidance 
" » de 
Brakmo, L., O'Malley, S., et L. Peterson, mais voir le RFC 6297 pour un 
tour d'horizon général.)

Où est-ce que LEDBAT va être mis en œuvre ? Cela peut être dans un 
protocole de transport, par exemple comme une extension de TCP, ou bien 
dans l'application. LEDBAT est un algorithme, pas un protocole précis. 
Il peut être utilisé dans plusieurs protocoles, du moment que ceux-ci 
permettent l'estampillage temporel des paquets, pour que les deux 
machines qui communiquent puissent mesurer le temps de voyage (section 
4.1).
 
La section 2 décrit l'algorithme exact. LEDBAT a une fenêtre de 
congestion, notée cwnd qui indique combien d'octets l'émetteur peut 
envoyer avant un nouvel accusé de réception. L'émetteur met dans chaque 
paquet le moment où il a envoyé ce paquet. Le récepteur regarde 
l'heure, en déduit le temps de voyage (aller simple, puisque 
l'encombrement n'est pas forcément le même dans les deux sens, une 
mesure aller-retour ne servirait pas à grand'chose) et retransmet cette 
indication à l'émetteur. Lorsque celui-ci voit le temps de v