- Son constat de base sur les portails, c'est finalement le même que celui des thuriféraires de la neutralité des réseaux avec la notion de Minitel 2.0
- la notion de communication efficaces et équitables c'es pas une invention de Ridiguel, c'est juste l'un des principaux champs de recherche en ingénierie réseau depuis 30 ans. Suffit de faire une recherche sur google pour flow fairness ou tcp fairness. Ca fait partie du problème plus vaste d'allocation des ressources sur un réseau qui est l'un des champs de recherche majeurs souhaité par l'Internet Architecture Board genre là : http://groups.csail.mit.edu/ana/Publications/DevelopingaNext(...) . C'est suffisamment d'actualité pour donner lieu à des débats houleux et récents autour de propositions radicales : http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02
- faire de la différentiation de services, c'est vieux comme IP. Y'a eu le champ Precedence, y'a eu ToS, maintenant on a DiffServ, etc. Bref on veut faire de la QoS depuis le début. Simplement parce que différents flux ont différentes contraintes (latence, débit, gigue, etc.). C'est pas l'antithèse de la neutralité des réseaux. De toute façon la neutralité est une notion politique plus que technique, le principe end-to-end qui est à son origine est beaucoup moins rigoureux (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen(...) qui dit que des fois il vaut mieux implémenter une fonction dans le réseau plutôt que dans l'application si ça améliore les performances...) tout comme la culture de pragmatisme qui règne à l'IETF. Comme Lawrence Lessig l'a déjà expliqué, le problème c'est pas la notion de services différenciés, c'est que l'opérateur en profite pour favoriser son contenu ou celui de ses partenaires commerciaux (source : http://online.wsj.com/article/SB122929270127905065.html ). Il faut juste que la QoS reste entre les mains des utilisateurs finaux et on est bon.
- l'intelligence dans le réseau ça fait un bout de temps qu'il y en a. Il existe plus depuis longtemps ce réseau idiot idéalisé. Il y a des tas d'éléments actifs qui maintiennent des états concernant les flux en cours. Or la notion du réseau idiot c'est qu'il ne devait pas maintenir d'états, c'est la source de l'opposition entre IP et ATM, entre les ingé réseaux et les téléphonistes. Mais depuis on a des firewalls, du NAT, de la QoS, du policy-based routing (i.e. pas que basé sur des critères purement techniques), du traffic engineering, etc. Ca fait bien longtemps que le réseau est intelligent. Et encore une fois, il peut y avoir de bonnes raisons. Le problème c'est si ça sert pour faire la discrimination qui réduit la liberté d'expression ou d'entreprendre. Bref c'est un problème d'appliquer les lois qui existent déjà dans un cadre nouveau.
Sur les critiques qui sont formulées de la pensée supposée de Ridiguel :
- Très bonne remarque, les pouvoirs publics auraient dû faire le forcing sur l'interopérabilité et les standards ouverts et on aurait une offre beaucoup plus variée et plus de compétition ce qui compenserait les dérives actuelles notamment sur la vie privée.
- Sur ton second point en gros tu plaides le retour aux quotas de trafic avec certaines classes de trafic hors quota. Ca m'étonnerait que le consommateur suive et en tout cas je vois mal le moindre opérateur s'y risquer. Et ce que tu décris ça impose quand même d'avoir une classification à un endroit, au plus proche de la source. Mais c'est exactement comme ça que fonctionne la QoS. Nul besoin d'opposer quantité et qualité, tu parles de la même chose. D'ailleurs, un réseau je peux le saturer même sans envoyer énormément de donnée. Il suffit d'avoir des flux non coopératifs qui foutent en l'air l'équité et du point de vue d'un flux individuel ça revient à avoir un réseau saturé (ex : http://www.cs.northwestern.edu/~akuzma/rice/shrew/ ou http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf ). Donc au final, j'ai quand même besoin d'avoir des buffers différents dans mes équipements réseau pour appliquer des algorithmes de gestion de file d'attente ou pour ordonnancer différemment les flux en fonction de ce que chacun a réellement besoin, ne serait-ce que pour garantir à ta classe "appel d'urgence" de pouvoir continuer à passer pendant que je rejette le trafic en vrac qui a dépassé le quota mais qui continue à venir me saturer une interface. Pour tout ça, soit les flux ont été taggués en amont et je fais confiance soit je cherche des heuristiques dans le paquet (i.e. de la DPI dans le cas plus extrême mais ça peut aussi être juste l'équivalent de NBAR de Cisco, cf. http://www1.cisco.com/en/US/products/ps6616/products_ios_pro(...) ). En tous cas il suffit pas juste de dire "il faut envoyer moins !". Le problème c'est d'empêcher que les opérateurs choisissent les politiques de QoS eux-mêmes sous couvert d'accords commerciaux parce que ça désavantage le consommateur mais sinon y'a rien d'intrinsèquement mauvais à faire de la QoS et donc de la différentiation.
Globalement je trouve que c'est faire bien grand cas de ce bonhomme qui ne dit rien de bien intéressant et qui est loin d'avoir l'aura que cet article semble vouloir lui attribuer. Il est juste particulièrement opportuniste.
PS : je vais me faire descendre mais je trouve en plus que les spécifications fonctionnelles des moyens de sécurisation HADOPI sont bien. Elles serviront juste à labelliser et ce qui est décrit c'est grosso modo ce que sait faire un Symantec Endpoint Protection et assimilés. Il est sans arrêt dit que l'utilisateur peut contrôler la politique de sécurité. Le seul truc supplémentaire par rapport à l'offre commerciale existante c'est 1) le coup de la copie des logs signés pour avoir une valeur en justice et 2) en plus des listes d'url commerciales, on aura des listes d'url gouvernementales mais a priori publiques ne serait-ce que pour des raisons purement techniques (genre le logiciel peut être open source et l'utilisateur garde le contrôle de la politique de sécurité). Limite ça va améliorer l'équipement en outils de sécurité sur les postes des français. En tous cas j'ai pas vu en quoi c'était un mouchard...
# En vrac
Posté par vjm . En réponse à la dépêche Michel Riguidel et la Hadopi. Évalué à 10.
- la notion de communication efficaces et équitables c'es pas une invention de Ridiguel, c'est juste l'un des principaux champs de recherche en ingénierie réseau depuis 30 ans. Suffit de faire une recherche sur google pour flow fairness ou tcp fairness. Ca fait partie du problème plus vaste d'allocation des ressources sur un réseau qui est l'un des champs de recherche majeurs souhaité par l'Internet Architecture Board genre là : http://groups.csail.mit.edu/ana/Publications/DevelopingaNext(...) . C'est suffisamment d'actualité pour donner lieu à des débats houleux et récents autour de propositions radicales : http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02
- faire de la différentiation de services, c'est vieux comme IP. Y'a eu le champ Precedence, y'a eu ToS, maintenant on a DiffServ, etc. Bref on veut faire de la QoS depuis le début. Simplement parce que différents flux ont différentes contraintes (latence, débit, gigue, etc.). C'est pas l'antithèse de la neutralité des réseaux. De toute façon la neutralité est une notion politique plus que technique, le principe end-to-end qui est à son origine est beaucoup moins rigoureux (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen(...) qui dit que des fois il vaut mieux implémenter une fonction dans le réseau plutôt que dans l'application si ça améliore les performances...) tout comme la culture de pragmatisme qui règne à l'IETF. Comme Lawrence Lessig l'a déjà expliqué, le problème c'est pas la notion de services différenciés, c'est que l'opérateur en profite pour favoriser son contenu ou celui de ses partenaires commerciaux (source : http://online.wsj.com/article/SB122929270127905065.html ). Il faut juste que la QoS reste entre les mains des utilisateurs finaux et on est bon.
- l'intelligence dans le réseau ça fait un bout de temps qu'il y en a. Il existe plus depuis longtemps ce réseau idiot idéalisé. Il y a des tas d'éléments actifs qui maintiennent des états concernant les flux en cours. Or la notion du réseau idiot c'est qu'il ne devait pas maintenir d'états, c'est la source de l'opposition entre IP et ATM, entre les ingé réseaux et les téléphonistes. Mais depuis on a des firewalls, du NAT, de la QoS, du policy-based routing (i.e. pas que basé sur des critères purement techniques), du traffic engineering, etc. Ca fait bien longtemps que le réseau est intelligent. Et encore une fois, il peut y avoir de bonnes raisons. Le problème c'est si ça sert pour faire la discrimination qui réduit la liberté d'expression ou d'entreprendre. Bref c'est un problème d'appliquer les lois qui existent déjà dans un cadre nouveau.
Sur les critiques qui sont formulées de la pensée supposée de Ridiguel :
- Très bonne remarque, les pouvoirs publics auraient dû faire le forcing sur l'interopérabilité et les standards ouverts et on aurait une offre beaucoup plus variée et plus de compétition ce qui compenserait les dérives actuelles notamment sur la vie privée.
- Sur ton second point en gros tu plaides le retour aux quotas de trafic avec certaines classes de trafic hors quota. Ca m'étonnerait que le consommateur suive et en tout cas je vois mal le moindre opérateur s'y risquer. Et ce que tu décris ça impose quand même d'avoir une classification à un endroit, au plus proche de la source. Mais c'est exactement comme ça que fonctionne la QoS. Nul besoin d'opposer quantité et qualité, tu parles de la même chose. D'ailleurs, un réseau je peux le saturer même sans envoyer énormément de donnée. Il suffit d'avoir des flux non coopératifs qui foutent en l'air l'équité et du point de vue d'un flux individuel ça revient à avoir un réseau saturé (ex : http://www.cs.northwestern.edu/~akuzma/rice/shrew/ ou http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf ). Donc au final, j'ai quand même besoin d'avoir des buffers différents dans mes équipements réseau pour appliquer des algorithmes de gestion de file d'attente ou pour ordonnancer différemment les flux en fonction de ce que chacun a réellement besoin, ne serait-ce que pour garantir à ta classe "appel d'urgence" de pouvoir continuer à passer pendant que je rejette le trafic en vrac qui a dépassé le quota mais qui continue à venir me saturer une interface. Pour tout ça, soit les flux ont été taggués en amont et je fais confiance soit je cherche des heuristiques dans le paquet (i.e. de la DPI dans le cas plus extrême mais ça peut aussi être juste l'équivalent de NBAR de Cisco, cf. http://www1.cisco.com/en/US/products/ps6616/products_ios_pro(...) ). En tous cas il suffit pas juste de dire "il faut envoyer moins !". Le problème c'est d'empêcher que les opérateurs choisissent les politiques de QoS eux-mêmes sous couvert d'accords commerciaux parce que ça désavantage le consommateur mais sinon y'a rien d'intrinsèquement mauvais à faire de la QoS et donc de la différentiation.
Globalement je trouve que c'est faire bien grand cas de ce bonhomme qui ne dit rien de bien intéressant et qui est loin d'avoir l'aura que cet article semble vouloir lui attribuer. Il est juste particulièrement opportuniste.
PS : je vais me faire descendre mais je trouve en plus que les spécifications fonctionnelles des moyens de sécurisation HADOPI sont bien. Elles serviront juste à labelliser et ce qui est décrit c'est grosso modo ce que sait faire un Symantec Endpoint Protection et assimilés. Il est sans arrêt dit que l'utilisateur peut contrôler la politique de sécurité. Le seul truc supplémentaire par rapport à l'offre commerciale existante c'est 1) le coup de la copie des logs signés pour avoir une valeur en justice et 2) en plus des listes d'url commerciales, on aura des listes d'url gouvernementales mais a priori publiques ne serait-ce que pour des raisons purement techniques (genre le logiciel peut être open source et l'utilisateur garde le contrôle de la politique de sécurité). Limite ça va améliorer l'équipement en outils de sécurité sur les postes des français. En tous cas j'ai pas vu en quoi c'était un mouchard...
Pff trop long tout ça, désolé.