Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Bonjour Jean-Édouard, Le 10 novembre 2012 16:29, Pierre Emeriaud petrus...@gmail.com a Puisqu'on parle d'Internet OBS et d'IPv6, est-ce que quelqu'un a des soucis de perf vers google (notamment visible sur youtube et gmail) ? En IPv4 ca fonctionne très bien mais en IPv6 c'est souvent lent... :/ Je confirme ce point, cf mon mail du 6/11/12 http://www.mail-archive.com/frnog@frnog.org/msg21216.html regards, B.Sonntag --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
salut manu, Le 10 novembre 2012 09:00, Emmanuel Thierry a écrit : Du coup tu peux appliquer la stratégie contraire: faire essentiellement des connexions keepalive pour surcharger les CGN d'un opérateur qui refuse encore de passer à IPv6, par exemple au hasard un opérateur qui porte le nom de la couleur de son logo ! Hum, peut-être que d'autres auront d'autres infos plus récentes/précises, mais Orange ne refuse pas de passer à ipv6, tu ne peux pas dire ça. C'est juste que c'est un très gros réseau, avec beaucoup d'équipements, et donc forcément des soucis de compatibilité avec ipv6, donc ça prend du temps. Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Quand tu auras un réseau aussi grand et complexe à gérer on pourra en reparler ;) /pierre [0] http://www.orange-business.com/fr/presse/communiques/offres/IPv6.html [1] http://www.orange-business.com/fr/entreprise/communication/reseaux-internet/internet/business-internet/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Hi, Le 10 novembre 2012 16:29, Pierre Emeriaud petrus...@gmail.com a écrit : Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Je confirme et ça juste marche (tant en MPLS qu'en Internet). Et s'il n'y a pas plus de VRF en dual stack c'est que la demande n'est semble il pas forcement foudroyante pour le moment. Pour la partie Internet mon petit doigt me dit que J. Nicolle a surement son mot à dire. Cdt, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le 10 nov. 2012 à 17:07, Thomas Barandon t.baran...@gmail.com a écrit : Hi, Le 10 novembre 2012 16:29, Pierre Emeriaud petrus...@gmail.com a écrit : Coté OBS en revanche, l'ipv6 n'est pas activé par défaut, mais c'est possible. Je n'ai pas vu beaucoup de vpn clients dual stack mais il y en a, cf [0], et les accès internet sont également compatibles (cf [1]). Je confirme et ça juste marche (tant en MPLS qu'en Internet). Et s'il n'y a pas plus de VRF en dual stack c'est que la demande n'est semble il pas forcement foudroyante pour le moment. Pour la partie Internet mon petit doigt me dit que J. Nicolle a surement son mot à dire. Puisqu'on parle d'Internet OBS et d'IPv6, est-ce que quelqu'un a des soucis de perf vers google (notamment visible sur youtube et gmail) ? En IPv4 ca fonctionne très bien mais en IPv6 c'est souvent lent... :/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Bonjour à tous, je profite du créneau du vendredi pour poser une question qui peut paraître simpliste, espérant que ça limite l'effet linchage :-) Au détour de verres avec un ami l'autre soir, nous étions en train de réfléchir au pourquoi comment du push de données. Par exemple, on prennait l'exemple d'un site web qui notifie en temps réel aux abonnés les nouveaux événements les concernant. Biensûr, impossible pour le serveur de joindre les clients directement, ça serait trop simple. Ce qui implique que tous les clients soient connectés, en permanence. Oui mais ça pose un certain nombre de problèmes d'avoir beaucoup de connexions permanentes. Comme ça au pif je pense par exemple à la limite du nombre de FD disponible. Mais ceci sont des considérations systèmes. Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Le fait d'avoir des (dizaines de) milliers de clients qui se connectent (donc suivant une répartition aléatoire sur une période temporelle) vers une même destination, plutôt que d'avoir ce même (dizaine de) millier de connexions ouvertes? Comme vous l'aurez compris, je n'ai pas beaucoup de notions de ce que c'est beaucoup de clients. Si des dizaines de milliers c'est peu, on peut parler de centaines de milliers. C'est juste pour avoir une idée des bottleneck auquel vous êtes confrontés. Merci d'avoir lu jusqu'ici :-) Bon vendredi, bon appétit. -- François --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le 09/11/2012 11:45, François a écrit : Bonjour à tous, je profite du créneau du vendredi pour poser une question qui peut paraître simpliste, espérant que ça limite l'effet linchage :-) Bon vendredi ;) Au détour de verres avec un ami l'autre soir, nous étions en train de réfléchir au pourquoi comment du push de données. Par exemple, on prennait l'exemple d'un site web qui notifie en temps réel aux abonnés les nouveaux événements les concernant. Biensûr, impossible pour le serveur de joindre les clients directement, ça serait trop simple. Ce qui implique que tous les clients soient connectés, en permanence. Oui mais ça pose un certain nombre de problèmes d'avoir beaucoup de connexions permanentes. Comme ça au pif je pense par exemple à la limite du nombre de FD disponible. Mais ceci sont des considérations systèmes. Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? si tu exclus l'aspect système, tout dépend du volume que tu transmets. Pour moi que ce soit un paquet RTP ou HTTP d'un point de vu réseau ça revient au même. Le fait d'avoir des (dizaines de) milliers de clients qui se connectent (donc suivant une répartition aléatoire sur une période temporelle) vers une même destination, plutôt que d'avoir ce même (dizaine de) millier de connexions ouvertes? Pas plus de problème, par contre c'est quand le système qu'il y a derrière qui déraille que ça devient plus drole (ou si le réseau à provoqué la même situation). Si les tentatives de reconnexions sont lissées ça va, sinon Et bion ça sera un flood ;) Mais je pense que dans ce dernier cas ton système aura plus mal que mes tuyaux :) Comme vous l'aurez compris, je n'ai pas beaucoup de notions de ce que c'est beaucoup de clients. Si des dizaines de milliers c'est peu, on peut parler de centaines de milliers. C'est juste pour avoir une idée des bottleneck auquel vous êtes confrontés. J'espère que pour faire ton keepalive ton paquet fait pas 1Mo et que tu n'as pas 100k clients comme ça ;) Merci d'avoir lu jusqu'ici :-) Bon vendredi, bon appétit. Tchouss --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Bonjour François, Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Le fait d'avoir des (dizaines de) milliers de clients qui se connectent (donc suivant une répartition aléatoire sur une période temporelle) vers une même destination, plutôt que d'avoir ce même (dizaine de) millier de connexions ouvertes? C'est un sujet de multicast. L'opérateur peut n'avoir qu'un seul message à transmettre. Les routeurs intermédiaires répercutent le multicast vers d'autres routeurs. Seuls les routeurs les plus proches des abonnés savent si ceux-ci sont encore vivants. Cela fonctionne très bien en Ethernet. Cordialement, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
On 11/09/2012 11:45 AM, François wrote: Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Le problème du push est que cela implique des contraintes supplémentaires à gérer (quels sont les clients connectés et où) qui peuvent devenir assez lourdes lorsqu'il s'agit d'un pool de serveur. On risque de se retrouver avec des serveurs qui finissent par faire du polling pour faire le push (l'avantage est que, dans ce cas, c'est l'admin qui décide de l'intervalle de temps utilisé). Comme vous l'aurez compris, je n'ai pas beaucoup de notions de ce que c'est beaucoup de clients. Si des dizaines de milliers c'est peu, on peut parler de centaines de milliers. C'est juste pour avoir une idée des bottleneck auquel vous êtes confrontés. C'est très dépendant du service géré, des contraintes à satisfaire et du daemon utilisé. François --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Bonjour Michel, le multicast nous a traversé l'esprit. Sur un réseau local, facile, mais sur internet ? La plus part des FAI bloquent les paquets multicast non? -- François Le 9 nov. 2012 à 12:11, Michel Hostettler a écrit : Bonjour François, Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Le fait d'avoir des (dizaines de) milliers de clients qui se connectent (donc suivant une répartition aléatoire sur une période temporelle) vers une même destination, plutôt que d'avoir ce même (dizaine de) millier de connexions ouvertes? C'est un sujet de multicast. L'opérateur peut n'avoir qu'un seul message à transmettre. Les routeurs intermédiaires répercutent le multicast vers d'autres routeurs. Seuls les routeurs les plus proches des abonnés savent si ceux-ci sont encore vivants. Cela fonctionne très bien en Ethernet. Cordialement, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
On 09/11/2012 11:45, François wrote: Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Le fait d'avoir des (dizaines de) milliers de clients qui se connectent (donc suivant une répartition aléatoire sur une période temporelle) vers une même destination, plutôt que d'avoir ce même (dizaine de) millier de connexions ouvertes? D'un point de vue réseau, ce qui compte c'est le nombre de paquets. De ton point de vue, plus de sessions c'est aussi plus de charge sur les serveurs et les firewalls (si statefull). Mais coté serveur ça va dépendre des implémentations, puisqu'une ouverture de session peut consommer plus que le maintient de plus de connexions ouvertes. La question va plutôt être de savoir si tu as besoin de plus de paquets pour le keepalive que pour le triple handshake (supposant que tu fais du HTTP, donc du TCP) à chaque ré-ouverture de session. J'aurais tendance à favoriser le keepalive et le pipelining dès que l'applicatif le permet et dans l'espoir de maximiser la charge utile des paquets. Mais quitte à pousser la réflexion à ce stade, l'idéal est encore que tout l'applicatif soit optimisé : sérialisation, minimisation et compression de ce qui peut l'être, vrai gestion statefull des clients connectés, gestion de reconnexion transparente en cas de perte de la session malgré le kepalive... Dans ce cas un des points d'optimisation peut être la spécialisation de tes serveurs. Tu vas avoir différents rôles prédéfinis et différents comportements pour chaque rôles, avec des heuristiques à implémnter dans ton applicatif pour optimiser encore plus le comportement de ces rôles. Le cas typique de mon point de vue c'est le jeu et ligne ou le site social / de rencontre avec t'chat. La première distinction que tu peux faire, c'est statique v;s. dynamique. Sur le statique, ton objectif va être de profiter du pipelining, et ce qui va compter c'est la capacité de ton sous-système de stockage à accéder à tous les fichiers dans le délai du keepalive (parfois les 5 secondes par défaut d'Apache ne suffisent pas, mais quelle idée d'utiliser apache pour du statique ?). Ensuite dans le dynamique, tu vas avoir la génération des pages et le support de tes messages applicatifs. Sur la génération des pages, tu vas généralement n'avoir qu'un fichier à envoyer par requête, et les requêtes sont plutôt espacées, donc le keepalive ne sert à rien. Par contre sur la classe de serveurs qui va supporter la messagerie instantanée, tu as intérêt à l'augmenter au maximum dès qu'une conversation est active. Ou plutôt que ton code coté client n'initie la connexion que lorsqu'une conversation est effectivement démarrée. Sur un site un peu gros, pour le coup tu vas plutôt avoir 4 à 6 familles de serveurs frontaux : - Les statiques invariables (images) : ce sont les I/O disque random read qui chargent. Keepalive pour pipelining. - Les statiques légèrement variables (js, css) : tu vas bouffer un peu de CPU si tu ne pré-compresse pas, mais finalement tout le contenu se retrouve en RAM, donc peu d'IO disque. Keepalive pour pipelining. - Les dynamiques lourds (html) : ceux là tapent dans les bases pour génerer uniquement l'ossature et agréger le contenu que tu auras considéré comme statique. Pas de keepalive. - Les dynamiques légers (html aussi, parfois json ou xml) : ceux là vont générer des inclusions plus variables, genre le top 5 instantané ou la liste des connectés. Per request uniquement, pas de keepalive. - Les flux de contrôle par session (json ou autre) : ouverts pour tout le monde, pour les notifications quelconques, pas forcement très réactives donc un keepalive court et du polling toutes les 2-3 minutes peut suffire - Les flux applicatifs real-time (json ou autre) : là c'est spécialisé pour la messagerie instantanée, les données de jeu en ligne, ...). Keepalive long obligatoire. Sur chaque famille tu vas avoir des profils de requêtes par utilisateur assez différents pour avoir des optimisations adaptées à chaque scénario, et donc faire un meilleur usage du keepalive pour gagner en réactivité et minimiser la charge de tes serveurs. Le fait de découper les serveurs par fonction de permettra aussi de scaler et distribuer la charge (sous entendu en CDN et/ou sur plusieurs hébergeurs) plus facilement. @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le Fri, Nov 09, 2012 at 11:45:44AM +0100, François [aifs...@gmail.com] a écrit: Bonjour à tous, je profite du créneau du vendredi pour poser une question qui peut paraître simpliste, espérant que ça limite l'effet linchage :-) Avec un y, lynchage. [...] Pour vous opérateurs, ça change quelque chose le modèle push serveur - client (et donc le fait d'avoir des connexions persistantes)? Pour compléter ce que dit Jerome (en gros du point de vue réseau, on s'en fout, si le nombre de paquets est équivalent), y'a une catégorie de gens qui « font du réseau », qui ne seront pas complètement d'accord. Il s'agit de ceux qui font du NAT, et qui donc, doivent maintenir une table d'états des connexions établies. Pour eux, une connexion établie qui n'a pas d'activité (pendant X secondes), elle va couter de la ressource mémoire. (mais ceux qui font/vont-faire du Carrier-Grade-NAT sauront surement en dire plus :o) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le 09/11/2012 12:44, François a écrit : Bonjour Michel, le multicast nous a traversé l'esprit. Sur un réseau local, facile, mais sur internet ? La plus part des FAI bloquent les paquets multicast non? Le multicast c'est sur un réseau dont tu as la maitrise. Qu'il soit local ou non. Donc après on dépasse de ta question ;) Si tu collectes tes utilisateurs ou si ils établissent un lien direct avec ton réseau (du tunneling) tu peux utiliser le multicast. Mais de toute façon ça résout le problème de charge du sender, pas des receveur et du trafic réseau ... Le multicast est intéréssant si tu peux faire redescendre le trafic au plus pret des utilisateurs finaux ... l'IPTV utilise par exemple ce principe dans les réseaux FAI mais avec Netfix, c'est pas la même chose :) Donc a ta question initiale sur le principe pur réseau pseudo multicast Utilisateur Internet ou unicast le trafic sera kifkif et les problématique de transit et de répartition de tes clients aussi ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Le multicast c'est sur un réseau dont tu as la maitrise. Qu'il soit local ou non. Donc après on dépasse de ta question ;) En pratique, oui, mais en théorie rien n'empeche d'avoir du multicast Inter-AS. Scope IPv6 multicast routable sur Internet : ffxe::/16 En IPv4, les sources sont plus confuses : RFC6034http://tools.ietf.org/html/rfc6034 et RFC3180 http://tools.ietf.org/html/rfc3180 Après le problème est qu'il manque un protocole de routage pour le multicast Inter-AS digne de nom. Il fut un temps où des papiers tournaient sur un BGMP (et non pas MBGP), qui aurait repris le fonctionnement de PIM mais sur un fonctionnement proche de BGP à savoir utilisation de la notion d'AS (AS path, originating AS etc.) En partie normé dans la RFC3913 http://www.ietf.org/rfc/rfc3913.txt, il est depuis bel et bien abandonné (aucune implémentation, pas de nouveautés depuis 2004). Donc en pratique, chaque SP se construit sa propre plateforme IPTV, route les flux en 239.x.x.x, là où en théorie, une boite tierce (voire les fournisseurs de contenu) pourrait router le flux nativement en multicast pour les différents SP, et éviter ainsi de déployer moultes plateformes là où une ou deux par flux suffiraient. Poussez l'idée à Youtube, pour leurs chaines télés ça permettrait de les avoir en LiveFeed plutot qu'en OnDemand. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
Guillaume Barrot guillaume.bar...@gmail.com a écrit : Le multicast c'est sur un réseau dont tu as la maitrise. Qu'il soit local ou non. Donc après on dépasse de ta question ;) En pratique, oui, mais en théorie rien n'empeche d'avoir du multicast Inter-AS. Scope IPv6 multicast routable sur Internet : ffxe::/16 En IPv4, les sources sont plus confuses : RFC6034http://tools.ietf.org/html/rfc6034 et RFC3180 http://tools.ietf.org/html/rfc3180 Après le problème est qu'il manque un protocole de routage pour le multicast Inter-AS digne de nom. Il fut un temps où des papiers tournaient sur un BGMP (et non pas MBGP), qui aurait repris le fonctionnement de PIM mais sur un fonctionnement proche de BGP à savoir utilisation de la notion d'AS (AS path, originating AS etc.) En partie normé dans la RFC3913 http://www.ietf.org/rfc/rfc3913.txt, il est depuis bel et bien abandonné (aucune implémentation, pas de nouveautés depuis 2004). Donc en pratique, chaque SP se construit sa propre plateforme IPTV, route les flux en 239.x.x.x, là où en théorie, une boite tierce (voire les fournisseurs de contenu) pourrait router le flux nativement en multicast pour les différents SP, et éviter ainsi de déployer moultes plateformes là où une ou deux par flux suffiraient. Poussez l'idée à Youtube, pour leurs chaines télés ça permettrait de les avoir en LiveFeed plutot qu'en OnDemand. Bonjour, J'avais de mon côté entendu parler de MBone: http://www.savetz.com/mbone/ De mémoire, il n'y avait que RENATER raccordé à ce backbone en France, qui permettait la diffusion de webradio étudiante sur tous les campus. C'est mort ou ça existe encore? Cordialement, Fred --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] En tant que FAI, preferez vous beaucoup de connexion courtes, ou du keepalive?
On 2012-11-09 12:53, Jérôme Nicolle wrote: J'aurais tendance à favoriser le keepalive et le pipelining dès que l'applicatif le permet et dans l'espoir de maximiser la charge utile des paquets. il ne faut pas oublier un point qui peut paraitre critique. utiliser le keepalive te rends vulnérable aux attaques du genre slowloris, ce qui peut tomber ton serveur en 2 temps, 3 mouvements. --- Liste de diffusion du FRnOG http://www.frnog.org/
