On doit pouvoir aussi rajouter Native Client pour garder en cache des applications compilées assez complexes. Je pense à des jeux en particulier. Pour faire passer le temps avant que Gmail ou Wave ne puissent se remettre à jour...
Dans Chrome sous Windows, Gears est directement intégré. Dans Chromium sous Linux ce n'est pas le cas mais il y a des déclarations de devs Google disant que le futur c'est HTML 5.
J'en profite pour demander à ce que chaque personne invoquant le minitel 2.0 dans une nouvelle ou un commentaire soit obligé de justifier ses propos en faisant directement référence à la page des présentations ou à la minute des videos de Benjamin Bayart. Ou au moins à lire un argumentaire légèrement différent : http://www.mail-archive.com/frnog@frnog.org/msg07973.html
Il était très bien aussi dans Notre univers impitoyable (un vague remake de Sliding Doors avec Gwyneth Paltrow) où justement il jouait avec Alice Taglioni. C'est dommage c'était vraiment un acteur sous-utilisé et peu connu (même chez nos proches voisins outre-quiévrain *ahem* bref).
Rien ne dit qu'il ne s'agit pas de lancer le débat autour d'une mise à jour sérieuse de HTTP, la dernière tentative ayant échoué en 1999. Entre temps le web a beaucoup évolué et les besoins aussi. Et surtout, une règle de l'IETF est "We reject kings, presidents and voting. We believe in rough consensus and running code" [1]. Au moins là on a le running code et on peut évaluer. L'étape intelligente suivante c'est d'aller faire un BoF au prochain meeting IETF. C'est con, c'était cette semaine...
Reste à savoir si ca reste du Minitel 2.0 ou si c'est vraiment décentralisé.
Ca devient insupportable d'entendre Minitel 2.0 à tout bout de champ surtout dans la bouche de personnes qui selon toutes vraisemblances ne comprennent rien de ce qu'ils racontent.
C'est l'occasion où jamais de sortir cette citation de Banksy :
People are taking the piss out of you everyday. They butt into your life, take a cheap shot at you and then disappear. They leer at you from tall buildings and make you feel small. They make flippant comments from buses that imply you're not sexy enough and that all the fun is happening somewhere else. They are on TV making your girlfriend feel inadequate. They have access to the most sophisticated technology the world has ever seen and they bully you with it. They are The Advertisers and they are laughing at you.
You, however, are forbidden to touch them. Trademarks, intellectual property rights and copyright law mean advertisers can say what they like wherever they like with total impunity.
Fuck that. Any advert in a public space that gives you no choice whether you see it or not is yours. It's yours to take, re-arrange and re-use. You can do whatever you like with it. Asking for permission is like asking to keep a rock someone just threw at your head.
You owe the companies nothing. Less than nothing, you especially don't owe them any courtesy. They owe you. They have re-arranged the world to put themselves in front of you. They never asked for your permission, don't even start asking for theirs.
AT&T ne vend plus d'équipement réseau depuis 1996 lorsque AT&T Technologies est devenu une entité distincte appelée Lucent. Sans compter que AT&T aujourd'hui est en fait SBC qui a racheté AT&T en 2005 et récupéré la marque avec.
Par contre, il y a un phénomène intéressant et peu souligné sur la raison qui pousse des groupes d'intérêt étrangers à être présent à Bruxelles. L'UE est devenu le plus gros marché mondial régulé par une unique entité supra-nationale. L'importance de l'UE en tant que marché fait que chaque décision de régulation économique majeure de l'UE a des effets dans le monde entier. Ca a en particulier été le cas sur les directives RoHS (norme environnementale dans l'électronique) ou REACH (régulation de la mise sur le marché des substances chimiques).
Il y une sorte de soft power européenne très discrète qui se met en place de cette façon. Il y a même eu il y a quelques mois des articles assez agressifs dans la presse économique américaine à ce sujet. Je ne trouve plus les références exactes mais grosso modo ça disait que les entreprises européennes avaient un avantage compétitif puisqu'elles devaient suivre les normes européennes avant tout le monde en ayant bien le temps de peser dessus et de se préparer alors qu'ensuite ces normes se diffusaient à l'international à cause de la puissance économique du marché européen. D'où des coups de mise aux normes plus élevés pour les entreprises américaines.
Le résultat c'est que les américains notamment se mettent à venir faire du lobbying en Europe pour éviter que des précédents s'y créent et ne s'exportent chez eux.
Amusant, l'étude a l'air sponsorisé par Intel mais ils utilisent des processeurs AMD. Cela dit ça va pas beaucoup mieux que les études de Tally ou les data sheets triomphantes de Vyatta. On mesure du forwarding pur avec des paquets 64KB pour faire des gros chiffres en PPS, générés depuis un autre Linux (en termes de méthodologie, tu es quasiment en train de mesurer avec ce que tu mesures...). Je vois presque jamais de tests effectués avec des Ixia/Agilentet du trafic imix.
Et c'est sans compter sur le fait que aussi bon que le PCIe puisse être en réseau, l'architecture PC typique n'est simplement pas faite et ne sera jamais faite pour router et forwarder efficacement, wire-speed et non-blocking, avec des backplane de la famille crossbar, surtout si on se met à vouloir une densité de ports à peu près correcte (et si en plus c'est que du ports gig ou 10 gig, on va exploser le budget comparé à un routeur ou un switch multi-layer classique).
Le 10Gig sous Linux ou FreeBSD il est essentiellement poussé par des fabriquant de matériel dédié aux SAN ou au calculateurs. Et souvent on se retrouve à offloader le plus possible sur ces NIC à tel point qu'on peut plus vraiment dire que c'est la pile TCP/IP de Linux ou FreeBSD qui fait le travail.
Il faut lire les articles d'Andre Opperman sur l'amélioration de la pile TCP/IP de FreeBSD pour s'en rendre compte. Et il faut lire aussi Network Algorithmics et les articles de Varghese pour comprendre ce qu'il peut manquer à un PC.
Sans même aborder le niveau déprimant des logiciels de routage (même si s'améliore un peu grâce notamment à Claudio Jeker d'OpenBSD) et le manque de cohérence total de l'ensemble qui en fait un vrai cauchemar à administrer.
Bref, c'est tout à fait valable pour une faible densité de ports avec pas trop de trafic, genre un CPE d'une petite boîte ou un backup d'une plus grosse. Si ça marchait si bien que ça, Vyatta aurait déjà détrôné Cisco.
Va falloir se réveiller un peu. Ca suffit d'entendre sans arrêt qu'il suffit d'utiliser Linux ou un BSD pour faire routeur. Au-delà d'un ou deux Gbps à router, tu peux pas t'en sortir avec du hardware choisi sur étagère et du logiciel d'usage général.
Et je suis un fanboy FreeBSD.
Cela étant dit, l'IPv6 commence à être prix en charge sur un grand nombre d'équipement chez un grand nombre de constructeurs. Le problème c'est les bugs et les incompatibilités (et quelques fois les performances quand il n'y a pas de prise en charge hardware et qu'on se retrouve à passer par le slow path pour du routeur de coeur). En coeur l'autre problème, pour les constructeurs, c'est de fabriquer des machines avec des TCAM assez grandes pour tenir des tables de routage IPv6.
On trouve effectivement plus de documentation en cherchant "Carrier-Grade NAT". Il y a eu une conférence très intéressante à ce sujet lors de la récente HAR2009 : https://har2009.org/program/events/95.en.html
Il faut bien voir que l'IETF (en tant que communauté) désire plus que tout qu'IPv6 triomphe pour restaurer la transparence d'Internet (RFC 2775 et 4924 notamment). Mais il y a désormais un consensus qui s'est installé sur le fait que la migration vers IPv6 a été mal préparé et que désormais dans l'urgence on aura du mal à simplement dire "passez à IPv6 !". CGN est notamment vu comme une solution intermédiaire qui pourra même servir d'étape de transition vers IPv6 (une fois que je NAT à cette échelle, je peux discrètement passer en IPv6 au niveau du coeur avant de migrer mes clients).
Sur quatre semaines il doit être mis en œuvre :
deux semaines consacrées à l’examen des textes du gouvernement,
une semaine consacrée à l’examen des textes proposés par les députés avec une journée réservée aux textes d’un groupe minoritaire,
une semaine de contrôle.
Google, 4 secondes, assez dit.
C'est plus l'absence de "bipartisanisme" et le fait majoritaire qui est à remettre en cause. Et ça se corrige difficilement avec des lois.
En plus, La Quadrature du Net avait commencé à analyser l'avant-projet Loppsi et franchement d'un point juridique (et constitutionnel) c'est assez bien ficelé et inattaquable. Le seul vrai point sombre c'est la théorie du pied dans la porte : on commence par permettre les "perquisitions informatiques" et le filtrage pour des crimes odieux afin que le projet soit inattaquable et après on a plus qu'à étendre tout doucement l'exception.
Quant à Herisson, ça fait des années et des années que ce genre de système existe (en moins complet ou dans le domaine privé) et il se base uniquement sur des données publiques. À charge de chacun de faire le ménage devant sa porte.
Vous pensez vraiment que Sun a racheté VirtualBox juste pour faire joujou avec du windows dans opensolaris ?
Oui.
L'offre de virtualisation de Sun s'appelle xVM. xVM tout seul c'est la solution serveur et c'est basé sur Xen. xVM Virtualbox c'est la solution poste de travail destinée aux développeurs ou aux administrateurs pour tester avant de déployer sur xVM.
Niveau smartcard, on peut aussi faire dans le générateur OTP synchrone ou asynchrone. Il n'y a rien besoin de connecter. Dans le même genre on fait des générateurs OTP software pas mauvais qui fonctionnent partout (même sur iPhone chez RSA par exemple).
C'est une idée intéressante dans tous les cas de généraliser l'utilisation de jetons cryptographiques pour des abonnés. C'est notamment quelque chose que font les banques.
Il faut distinguer ce qu'il se passe à l'intérieur d'un flux de ce qui se passe entre plusieurs flux. Dans ton exemple, on s'intéresse au comportement automatiquement coopératif des flux TCP entre eux qui est une conséquence des algorithmes mis en oeuvre par TCP. Si j'ai plein de sessions sur un même lien qui naissent et qui meurent sans arrêt en faisant plein de trafic, je vais augmenter la congestion qui va être détectée individuellement par chaque flux et qui par conséquent vous s'adapter autour du nouveau débit optimal sans perte.
Le truc sur lequel TCP est vraiment mauvais traditionnellement (mais comme je le disais, il y a des workarounds) c'est quand les pertes sont causées par autre chose que de la congestion.
Ca m'étonnerait que Free ait un /10 à gaspiller pour un service comme FreeWifi. Il faudrait que quelqu'un teste le service et nous dise quelle IP il a obtenu. On pourra recouper avec les enregistrements RIPE fait au nom de Free pour avoir une idée de l'espace alloué au service (après ça dépend si c'est un bloc complétement nouveau/différent ou bien une tranche d'un bloc déjà utilisé dans ce cas il y aura de la superposition avec des adresses qui correspondent effectivement à des abonnés donc potentiellement à une zone géographique).
Bon, c'est vrai que pour le fonctionnement de TCP je me suis un peu trompé, même si la deuxième partie de ton explication correspond à ce que je décrivais : on pousse jusqu'au max possible avant de perdre des paquets, et là on diminue un peu.
Sauf que *les* algorithmes en jeu sont un peu plus compliqués que ça. D'une part, globalement on fait de l'Additive Increase Multiple Decrease (AIMD) ce qui signifie que tous les algorithmes contrôlant la taille de la fenêtre la font toujours décroître plus violemment qu'ils ne la font croître. C'est l'origine du fameux comportement oscillatoire de TCP quand on graphe une session.
Par contre ce qu'on voit aussi quand on graphe une session, c'est que au début ça monte très vite et après ça fait de plus petites oscillations autour du débit optimal. C'est parce que au début d'une session ou juste après la détection d'une congestion, on est en Slow Start (ou en Fast Recovery dans des piles plus modernes) qui est un algorithme qui croît exponentiellement. Une fois qu'on a passé un certain seuil (qui typiquement dépend du Maximum Segment Size négocié en début de session), on bascule en Congestion Avoidance qui lui croît de façon linéaire.
Grosso modo, on a un comportement plutôt très sensible à la congestion qui peut rapidement diminuer le débit et le ramener à un débit stable autour du débit optimal sans perte. C'est en cela que le shaping marche.
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Il le voit en fonction des ACK effectivement. Mais il surveille aussi le timing de ces ACK (ou surtout de leur absence ou celui des dupliqués). D'ailleurs on dit parfois qu'une session TCP est guidée par une horloge à ACK (ACK Clock, expression de Van Jacobson). Ca passe par le RTO (retransmission timeout) qui est calculé en fonction du temps d'aller-retour (round-trip time, RTT) et de sa variation. Ca veut dire que plus j'ai de trafic plus je suis considéré comme sensible à la congestion et donc plus la granularité de mon horloge à ACK est élevée et plus je retransmets facilement.
Bref, si tu réintroduis ce que j'ai expliqué sur Slow Start et Congestion Avoidance, ça veut dire que si tu shape que dans sur le descendant (par rapport au client), tu vas certes répondre vite et provoquer une détection rapide de congestion mais à cause de la nature AIMD des algorithmes utilisés, tu vas aussi oscillé plus vite et aller te stabiliser plus vite autour du débit optimal sans perte, c'est-à-dire celui qui correspond au shaping.
C'est pour ça qu'il y avait des tutoriaux pour OpenBSD PF qui montraient comment prioritiser les ACK sur tes sessions SSH pour bien garder l'interactivité d'une telle session TCP.
C'est mon avis et je le partage.
PS : TCP on dit souvent que c'est dans la RFC 793 mais il faut au moins rajouter la 896, 1122, la 1323, la 2001, la 2585 sans parler de toutes celles qui fleurissent sur des modifications des algorithmes d'évitement de congestion soit dans des cas généraux (genre l'Appropriate Byte Counting qu'il y a sous Linux) soit dans des cas particuliers (il y a des algorithmes plus mieux pour les liens qui tendent naturellement à avoir plus de pertes sans que ça indique une congestion comme le sans-fil).
C'est assez récent et c'est une grosse repompe de la stratégie d'HMV au Royaume-Uni qui fait ça depuis des années et où leurs ventes de CDs et de DVDs ne s'effondrent pas...
La réaction de Guy Bono, l'un des rédacteurs de l'amendement 138 original (oui parce que celui qui a été voté là c'est le même texte que le 138 mais son numéro c'est 46) : http://www.guy-bono.fr/article/articleview/8924/1/1378/
[^] # Re: Obligation d'utiliser une clef 3G
Posté par vjm . En réponse au journal GoogleOS / ChromeOS / minitel 2. Évalué à 1.
[^] # Re: Obligation d'utiliser une clef 3G
Posté par vjm . En réponse au journal GoogleOS / ChromeOS / minitel 2. Évalué à 10.
C'est plus utile avec Internet mais c'est pas indispensable pour s'en servir :
http://gears.google.com/
http://www.w3.org/TR/offline-webapps/
Dans Chrome sous Windows, Gears est directement intégré. Dans Chromium sous Linux ce n'est pas le cas mais il y a des déclarations de devs Google disant que le futur c'est HTML 5.
J'en profite pour demander à ce que chaque personne invoquant le minitel 2.0 dans une nouvelle ou un commentaire soit obligé de justifier ses propos en faisant directement référence à la page des présentations ou à la minute des videos de Benjamin Bayart. Ou au moins à lire un argumentaire légèrement différent : http://www.mail-archive.com/frnog@frnog.org/msg07973.html
# Notre univers impitoyable
Posté par vjm . En réponse au journal Jocelyn Quivrin bronsonisé. Évalué à 1.
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par vjm . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 3.
[1] http://www.ietf.org/tao.html
[^] # Re: Push
Posté par vjm . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 10.
Ca devient insupportable d'entendre Minitel 2.0 à tout bout de champ surtout dans la bouche de personnes qui selon toutes vraisemblances ne comprennent rien de ce qu'ils racontent.
[^] # Re: Le "Problème"
Posté par vjm . En réponse au journal Spotify sans les pubs audio. Évalué à 3.
People are taking the piss out of you everyday. They butt into your life, take a cheap shot at you and then disappear. They leer at you from tall buildings and make you feel small. They make flippant comments from buses that imply you're not sexy enough and that all the fun is happening somewhere else. They are on TV making your girlfriend feel inadequate. They have access to the most sophisticated technology the world has ever seen and they bully you with it. They are The Advertisers and they are laughing at you.
You, however, are forbidden to touch them. Trademarks, intellectual property rights and copyright law mean advertisers can say what they like wherever they like with total impunity.
Fuck that. Any advert in a public space that gives you no choice whether you see it or not is yours. It's yours to take, re-arrange and re-use. You can do whatever you like with it. Asking for permission is like asking to keep a rock someone just threw at your head.
You owe the companies nothing. Less than nothing, you especially don't owe them any courtesy. They owe you. They have re-arranged the world to put themselves in front of you. They never asked for your permission, don't even start asking for theirs.
Source : http://en.wikiquote.org/wiki/Banksy
[^] # Re: Ah... on va pouvoir sortir un routeur Hadopi !
Posté par vjm . En réponse au journal WNR3500L : le routeur "Open Source" de Netgear. Évalué à 3.
[^] # Re: AT&T ?
Posté par vjm . En réponse au journal Agir maintenant pour sauver la neutralité du Net !. Évalué à 3.
Par contre, il y a un phénomène intéressant et peu souligné sur la raison qui pousse des groupes d'intérêt étrangers à être présent à Bruxelles. L'UE est devenu le plus gros marché mondial régulé par une unique entité supra-nationale. L'importance de l'UE en tant que marché fait que chaque décision de régulation économique majeure de l'UE a des effets dans le monde entier. Ca a en particulier été le cas sur les directives RoHS (norme environnementale dans l'électronique) ou REACH (régulation de la mise sur le marché des substances chimiques).
Il y une sorte de soft power européenne très discrète qui se met en place de cette façon. Il y a même eu il y a quelques mois des articles assez agressifs dans la presse économique américaine à ce sujet. Je ne trouve plus les références exactes mais grosso modo ça disait que les entreprises européennes avaient un avantage compétitif puisqu'elles devaient suivre les normes européennes avant tout le monde en ayant bien le temps de peser dessus et de se préparer alors qu'ensuite ces normes se diffusaient à l'international à cause de la puissance économique du marché européen. D'où des coups de mise aux normes plus élevés pour les entreprises américaines.
Le résultat c'est que les américains notamment se mettent à venir faire du lobbying en Europe pour éviter que des précédents s'y créent et ne s'exportent chez eux.
[^] # Re: IPV6 n'existe pas
Posté par vjm . En réponse au journal IP v6 sur Linuxfr.org. Évalué à 2.
Et c'est sans compter sur le fait que aussi bon que le PCIe puisse être en réseau, l'architecture PC typique n'est simplement pas faite et ne sera jamais faite pour router et forwarder efficacement, wire-speed et non-blocking, avec des backplane de la famille crossbar, surtout si on se met à vouloir une densité de ports à peu près correcte (et si en plus c'est que du ports gig ou 10 gig, on va exploser le budget comparé à un routeur ou un switch multi-layer classique).
Le 10Gig sous Linux ou FreeBSD il est essentiellement poussé par des fabriquant de matériel dédié aux SAN ou au calculateurs. Et souvent on se retrouve à offloader le plus possible sur ces NIC à tel point qu'on peut plus vraiment dire que c'est la pile TCP/IP de Linux ou FreeBSD qui fait le travail.
Il faut lire les articles d'Andre Opperman sur l'amélioration de la pile TCP/IP de FreeBSD pour s'en rendre compte. Et il faut lire aussi Network Algorithmics et les articles de Varghese pour comprendre ce qu'il peut manquer à un PC.
Sans même aborder le niveau déprimant des logiciels de routage (même si s'améliore un peu grâce notamment à Claudio Jeker d'OpenBSD) et le manque de cohérence total de l'ensemble qui en fait un vrai cauchemar à administrer.
Bref, c'est tout à fait valable pour une faible densité de ports avec pas trop de trafic, genre un CPE d'une petite boîte ou un backup d'une plus grosse. Si ça marchait si bien que ça, Vyatta aurait déjà détrôné Cisco.
PS : network buzzword bingo!
[^] # Re: IPV6 n'existe pas
Posté par vjm . En réponse au journal IP v6 sur Linuxfr.org. Évalué à 4.
Et je suis un fanboy FreeBSD.
Cela étant dit, l'IPv6 commence à être prix en charge sur un grand nombre d'équipement chez un grand nombre de constructeurs. Le problème c'est les bugs et les incompatibilités (et quelques fois les performances quand il n'y a pas de prise en charge hardware et qu'on se retrouve à passer par le slow path pour du routeur de coeur). En coeur l'autre problème, pour les constructeurs, c'est de fabriquer des machines avec des TCAM assez grandes pour tenir des tables de routage IPv6.
[^] # Re: Avant de partir en trolls poilus dans tous les sens .....
Posté par vjm . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 3.
Il y a aussi un petit article d'introduction chez Network World : http://www.networkworld.com/community/node/44989
Il faut bien voir que l'IETF (en tant que communauté) désire plus que tout qu'IPv6 triomphe pour restaurer la transparence d'Internet (RFC 2775 et 4924 notamment). Mais il y a désormais un consensus qui s'est installé sur le fait que la migration vers IPv6 a été mal préparé et que désormais dans l'urgence on aura du mal à simplement dire "passez à IPv6 !". CGN est notamment vu comme une solution intermédiaire qui pourra même servir d'étape de transition vers IPv6 (une fois que je NAT à cette échelle, je peux discrètement passer en IPv6 au niveau du coeur avant de migrer mes clients).
[^] # Re: Un peu n'importe quoi
Posté par vjm . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 5.
Sur quatre semaines il doit être mis en œuvre :
deux semaines consacrées à l’examen des textes du gouvernement,
une semaine consacrée à l’examen des textes proposés par les députés avec une journée réservée aux textes d’un groupe minoritaire,
une semaine de contrôle.
Google, 4 secondes, assez dit.
C'est plus l'absence de "bipartisanisme" et le fait majoritaire qui est à remettre en cause. Et ça se corrige difficilement avec des lois.
[^] # Re: Un peu n'importe quoi
Posté par vjm . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 4.
En plus, La Quadrature du Net avait commencé à analyser l'avant-projet Loppsi et franchement d'un point juridique (et constitutionnel) c'est assez bien ficelé et inattaquable. Le seul vrai point sombre c'est la théorie du pied dans la porte : on commence par permettre les "perquisitions informatiques" et le filtrage pour des crimes odieux afin que le projet soit inattaquable et après on a plus qu'à étendre tout doucement l'exception.
Quant à Herisson, ça fait des années et des années que ce genre de système existe (en moins complet ou dans le domaine privé) et il se base uniquement sur des données publiques. À charge de chacun de faire le ménage devant sa porte.
[^] # Re: Sun VirtualBox
Posté par vjm . En réponse à la dépêche Tour d'horizon de la virtualisation libre. Évalué à 2.
Oui.
L'offre de virtualisation de Sun s'appelle xVM. xVM tout seul c'est la solution serveur et c'est basé sur Xen. xVM Virtualbox c'est la solution poste de travail destinée aux développeurs ou aux administrateurs pour tester avant de déployer sur xVM.
http://en.wikipedia.org/wiki/Sun_xVM
[^] # Re: Pitoyable
Posté par vjm . En réponse au journal [HADOPI] Opérations commandos de la ligue ODEBI. Évalué à 0.
[^] # Re: Desolay may...
Posté par vjm . En réponse au journal changement de coordonnées qui signifie perte de tout service pour l'éternité chez dedibox. Évalué à 2.
C'est une idée intéressante dans tous les cas de généraliser l'utilisation de jetons cryptographiques pour des abonnés. C'est notamment quelque chose que font les banques.
# EPIC FAIL
Posté par vjm . En réponse au journal Hadopi ou ?. Évalué à 7.
Il n'y a pas de cabale.
# Wait... what ?
Posté par vjm . En réponse à la dépêche Appel à Projets "Web 2.0": une opportunité pour le logiciel libre. Évalué à 5.
[^] # Re: QoS
Posté par vjm . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 1.
On appelle ça l'equal sharing ou la fairness de TCP. Il y a toute une polémique autour de ça depuis quelque temps parce que :
1) qu'est-ce qu'il se passe si on a des flux non coopératifs (cf. http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf ) ?
2) est-ce que ce fonctionnement est vraiment "juste" (cf. http://www.cs.ucl.ac.uk/staff/bbriscoe/projects/2020comms/re(...) )?
Le truc sur lequel TCP est vraiment mauvais traditionnellement (mais comme je le disais, il y a des workarounds) c'est quand les pertes sont causées par autre chose que de la congestion.
[^] # Re: 2ème IP publique
Posté par vjm . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 2.
[^] # Re: QoS
Posté par vjm . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 4.
Sauf que *les* algorithmes en jeu sont un peu plus compliqués que ça. D'une part, globalement on fait de l'Additive Increase Multiple Decrease (AIMD) ce qui signifie que tous les algorithmes contrôlant la taille de la fenêtre la font toujours décroître plus violemment qu'ils ne la font croître. C'est l'origine du fameux comportement oscillatoire de TCP quand on graphe une session.
Par contre ce qu'on voit aussi quand on graphe une session, c'est que au début ça monte très vite et après ça fait de plus petites oscillations autour du débit optimal. C'est parce que au début d'une session ou juste après la détection d'une congestion, on est en Slow Start (ou en Fast Recovery dans des piles plus modernes) qui est un algorithme qui croît exponentiellement. Une fois qu'on a passé un certain seuil (qui typiquement dépend du Maximum Segment Size négocié en début de session), on bascule en Congestion Avoidance qui lui croît de façon linéaire.
Grosso modo, on a un comportement plutôt très sensible à la congestion qui peut rapidement diminuer le débit et le ramener à un débit stable autour du débit optimal sans perte. C'est en cela que le shaping marche.
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Il le voit en fonction des ACK effectivement. Mais il surveille aussi le timing de ces ACK (ou surtout de leur absence ou celui des dupliqués). D'ailleurs on dit parfois qu'une session TCP est guidée par une horloge à ACK (ACK Clock, expression de Van Jacobson). Ca passe par le RTO (retransmission timeout) qui est calculé en fonction du temps d'aller-retour (round-trip time, RTT) et de sa variation. Ca veut dire que plus j'ai de trafic plus je suis considéré comme sensible à la congestion et donc plus la granularité de mon horloge à ACK est élevée et plus je retransmets facilement.
Bref, si tu réintroduis ce que j'ai expliqué sur Slow Start et Congestion Avoidance, ça veut dire que si tu shape que dans sur le descendant (par rapport au client), tu vas certes répondre vite et provoquer une détection rapide de congestion mais à cause de la nature AIMD des algorithmes utilisés, tu vas aussi oscillé plus vite et aller te stabiliser plus vite autour du débit optimal sans perte, c'est-à-dire celui qui correspond au shaping.
C'est pour ça qu'il y avait des tutoriaux pour OpenBSD PF qui montraient comment prioritiser les ACK sur tes sessions SSH pour bien garder l'interactivité d'une telle session TCP.
C'est mon avis et je le partage.
PS : TCP on dit souvent que c'est dans la RFC 793 mais il faut au moins rajouter la 896, 1122, la 1323, la 2001, la 2585 sans parler de toutes celles qui fleurissent sur des modifications des algorithmes d'évitement de congestion soit dans des cas généraux (genre l'Appropriate Byte Counting qu'il y a sous Linux) soit dans des cas particuliers (il y a des algorithmes plus mieux pour les liens qui tendent naturellement à avoir plus de pertes sans que ça indique une congestion comme le sans-fil).
# gni?
Posté par vjm . En réponse au journal Commission Européenne - Rendre les développeurs juridiquement responsables de leurs développements ?. Évalué à 3.
Ca veut rien dire ratage mercantile. Ou comment passer de la science économique à la critique politique en traduisant un terme.
http://fr.wikipedia.org/wiki/Defaillance_du_marche
[^] # Re: L'artiste engagé mais pas trop.
Posté par vjm . En réponse au journal Un artiste qiu parle argent, enfin. Évalué à 2.
[^] # Re: Originel ou original ?
Posté par vjm . En réponse au journal Amendement 138 version originale. Évalué à 7.
http://www.laquadrature.net/en/amendment-138-46-adopted-agai(...)
Un article sur ecrans.fr avec le décompte du vote :
http://www.ecrans.fr/Amendement-138-Vote,7122.html
La réaction de Guy Bono, l'un des rédacteurs de l'amendement 138 original (oui parce que celui qui a été voté là c'est le même texte que le 138 mais son numéro c'est 46) :
http://www.guy-bono.fr/article/articleview/8924/1/1378/
Numerama et PCInpact en parle aussi.
[^] # Re: Support
Posté par vjm . En réponse à la dépêche Sortie de FreeBSD 7.2. Évalué à 2.