Re: [FRnOG] [TECH] RFC 6789: ConEx Concepts and Use Cases
On Thu, Dec 6, 2012, at 16:57, Michel Hostettler wrote: (3) Un autre effet de la congestion, le retard, n'est pas pris en compte. Quel retard ? Celui a cause du buffering ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
Merci Stéphane, pour ces précisions Je crains que la compréhension fine des mécanismes télécoms passe par le bon usage du français, plutôt qu'une traduction approximative et simplificatrice d'une écriture anglaise déjà stylisée. Nous voyons ici que l'état de congestion doit être dissocié de l'état d'une file d'attente prête à atteindre une limite de débordement. Cordialement, Michel Hostettler - Mail original - De: Stephane Bortzmeyer bortzme...@nic.fr À: Michel Hostettler michel.hostett...@telecom-paristech.fr Cc: frnog-t...@frnog.org Envoyé: Jeudi 6 Décembre 2012 22:21:56 Objet: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases On Thu, Dec 06, 2012 at 04:57:34PM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 400 lines which said: (1) La congestion est définie comme la probabilité de perte de paquet (ou de marquage par ECN. Lorsque le réseau est congestionné, on perd tout, on ne marque pas. Oui, c'est le terme traditionnel mais ce n'est pas la définition du RFC. Le marquage est issu du contrôle de conformité d'un trafic par rapport à un profil préalablement souscrit par le client. Non, il s'agissait là de marquage ECN http://www.bortzmeyer.org/3168.html (3) Un autre effet de la congestion, le retard, n'est pas pris en compte. Quel retard ? Si les tampons des routeurs sont de grande taille, un trafic intense ne va pas entraîner de pertes de paquets (tant que les tampons ne sont pas pleins), mais des retards (le paquet va attendre longtemps dans le tampon). C'est le phénomène parfois critiqué sous le nom de « bufferbloat » (car certains réclament des tampons plus petits). --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 10:30:48AM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 56 lines which said: Je crains que la compréhension fine des mécanismes télécoms passe par le bon usage du français, Ben, c'est pas ce que j'ai fait ? Et comment dois-je prendre « traduction approximative et simplificatrice » ? Comme une critique ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 7, 2012, at 10:30, Michel Hostettler wrote: Nous voyons ici que l'état de congestion doit être dissocié de l'état d'une file d'attente prête à atteindre une limite de débordement. Une file d'attente prete a atteindre une limite de debordement signifie que ca faisait quelque temps que le paquets qui doivent a etre envoyes arrivent plus vite que le reseau peut les envoyer. Ce n'est pas de la congestion ca ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
Bonjour, Cf. CNTRL Congestion : état pathologique provoqué par une accumulation excessive de sang dans les vaisseaux d'un organe ou d'un tissu. Dans la congestion d'une file d'attente, l'état pathologique se traduit par la perte de données. Dans la file d'attente prête à atteindre une limite de débordement, aucune donnée n'est encore perdue. Et il est encore temps de pouvoir réagir. Cordialement, Michel Hostettler - Mail original - De: Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net À: Michel Hostettler michel.hostett...@telecom-paristech.fr, Stephane Bortzmeyer bortzme...@nic.fr Cc: frnog-t...@frnog.org Envoyé: Vendredi 7 Décembre 2012 10:48:40 Objet: Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases On Fri, Dec 7, 2012, at 10:30, Michel Hostettler wrote: Nous voyons ici que l'état de congestion doit être dissocié de l'état d'une file d'attente prête à atteindre une limite de débordement. Une file d'attente prete a atteindre une limite de debordement signifie que ca faisait quelque temps que le paquets qui doivent a etre envoyes arrivent plus vite que le reseau peut les envoyer. Ce n'est pas de la congestion ca ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 7, 2012, at 11:00, Michel Hostettler wrote: Cf. CNTRL Congestion : état pathologique provoqué par une accumulation excessive de sang dans les vaisseaux d'un organe ou d'un tissu. Dans la congestion d'une file d'attente, l'état pathologique se traduit par la perte de données. Dans la file d'attente prête à atteindre une limite de débordement, aucune donnée n'est encore perdue. Et il est encore temps de pouvoir réagir. Il suffit donc d'augmenter demesurement les buffers pour eliminer la congestion ?? Ca peut etre un point de vue, mais je ne le partage pas. Imaginez ce que ca pourrait donner d'avoir 128 GB de buffer par port. Ca fait ~1.5 secondes sur un lien 10G. Deja a 10-20ms de plus (que la latence native due a la distance) et les clients hurlent hysteriquement. Alors 1500ms... Pour moi la congestion c'est quand le *LIEN* (et non pas les buffers) est plein pendant assez longtemps. S'il y a deja plus de 2 paquets en attente dans les buffers, pour moi il y a congestion. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 11:49:32AM +0100, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 26 lines which said: Pour moi la congestion c'est quand le *LIEN* (et non pas les buffers) est plein pendant assez longtemps. S'il y a deja plus de 2 paquets en attente dans les buffers, pour moi il y a congestion. À noter que ce n'est pas la définition adoptée par le groupe de travail CONEX de l'IETF, probablement parce qu'elle est plus difficile à mesurer en pratique. Mais ce n'est pas un problème. Contrairement à ce que laisse entendre Michel Hostettler, il n'y a pas UNE définition correcte de la congestion, chacun a la sienne. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 11:00:03AM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 36 lines which said: Dans la congestion d'une file d'attente, l'état pathologique se traduit par la perte de données. Ce n'est pas la définition du groupe de travail CONEX (puisqu'il inclut aussi le marquage ECN, pas seulement l'abandon de paquets). Et je me méfie de termes sensationnalistes comme « état pathologique ». Il n'y a rien de pathologique à jeter des paquets, c'est un mécanisme normal d'IP. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] le super nouveau standard sorti du WCIT
On Thu, Dec 06, 2012 at 06:08:28PM +0100, sxpert sxp...@sxpert.org wrote a message of 9 lines which said: http://cryptome.org/2012/12/itu-future-networks.pdf Le texte adopté est décrit là http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11566 mais je n'ai pas encore trouvé le moyen de le télécharger (apparemment perdu lors d'une mise à jour du site). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] le super nouveau standard sorti du WCIT
On Fri, Dec 07, 2012 at 12:16:08PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 15 lines which said: Le texte adopté est décrit là http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11566 mais je n'ai pas encore trouvé le moyen de le télécharger (apparemment perdu lors d'une mise à jour du site). Ah ben voilà, il suffit d'attendre : http://www.itu.int/rec/T-REC-Y.2770/en In force mais pas encore publié, c'est l'ouverture à la mode UIT. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
Bonjour Radu-Adrien, Cf. CNTRL Congestion : état pathologique provoqué par une accumulation excessive de sang dans les vaisseaux d'un organe ou d'un tissu. Dans la congestion d'une file d'attente, l'état pathologique se traduit par la perte de données. Dans la file d'attente prête à atteindre une limite de débordement, aucune donnée n'est encore perdue. Et il est encore temps de pouvoir réagir. Il suffit donc d'augmenter demesurement les buffers pour eliminer la congestion ?? Ca peut etre un point de vue, mais je ne le partage pas. Vous faites un procès d'intention ! Mon commentaire n'exprime pas cela, vous l'avez probablement lu rapidement. Imaginez ce que ca pourrait donner d'avoir 128 GB de buffer par port. Ca fait ~1.5 secondes sur un lien 10G. Deja a 10-20ms de plus (que la latence native due a la distance) et les clients hurlent hysteriquement. Alors 1500ms... Vous développez inutilement le procès d'intention. Pour moi la congestion c'est quand le *LIEN* (et non pas les buffers) est plein pendant assez longtemps. S'il y a deja plus de 2 paquets en attente dans les buffers, pour moi il y a congestion. Le vidage des files d'attente en sortie de commutation ou de routage prend évidemment en compte la capacité de la liaison destinée à propager leur contenu. Cordialement, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [Urgent] Disaster Recovery IP Addressing
Bonjour la liste, Dans le cadre d'un projet de PCI, un nouveau DataCenter de Backup est à concevoir. Le premier point à voir: est-il préférable ou pas de garder le même plan d'adressage que le site primaire et utiliser des VIP sachant que sur beaucoup d'applications l'adressage est codé en dur ? Le but est de faire en prémier lieu de l'Actif/Backup manuel pour évoluer vers de l'actif/Actif sans nécessairement faire de la réplication synchrone(ce n'est pas une exigence). De point de vue système, une solution SRM Vmware sera utilisée. VMotion à voir aussi si la distance et le lien physique le permettra mais ce n'est pas vraiment le but? La distance entre les deux sites est de 240 Km et la liaison n'est pas de la fibre optique. Théoriquement, 3 grands Scénarios se posent: 1. faire l'image identique du 1er site tout en interdisant tout contact direct entre les deux sites en utilsant du Source NAT par exemple pour la réplication des donnés ou autres flux inter sites? Pour l'adressage public on jouera sur les poids des routes annoncés à l'identique de deux côté. 2. Garder le même plan d'adressage et utiliser des VIP, et propager les VLANs entre les deux sites pour faire des extensions de niveau 2 permettant ainsi de faire des probes sur les serveurs réparties sur les deux sites et détecter rapidement les pannes. Par contre, un problème de routage optimum se pose si on veut faire un failover à l'échelle d'une seule appli car on ne peut pas annoncer son /32 du côté du site secondaire sachant que cela sera filtré par l'operateur donc le flux INCOMING passera toujours par le site primaire et traversera le lien inter sites pour attaquer l'appli et le flux OUTCOMING sortira par la GW local du site secondaire (=routage asymétrique). 3. Utiliser un plan d'adressage complètement différent entre les deux sites et jouer sur le DNS public pour faire du failover ou du Load Balancing entre les deux sites. Sachant que le DNS public est géré par l'opérateur et que sur beaucoup des appli les adresseS IP sont codées en dur. Je ne sais pas si LISP est mis en oeuvre actuellement chez les opérateurs ou pas ou peut-être il n'y aurai pas besoin ? Je ne sais pas si des solutions Cisco GSS (Global Site Selector) avec ACE existent chez les opérateurs ou pas? Bien cordialement, Merci d'avance de votre aide. --- Liste de diffusion du FRnOG http://www.frnog.org/
