• L'avantage de ce protocole est qu'il est lié à Radius, donc on a un nombre important d'informations sur l'utilisateur à l'instant T : On sait (si on a un accounting cohérent et un système de requêtage intelligent) si un client est connecté, le moment de sa dernière coupure (que ce soit à l'initiative de l'abonné ou celle de l'équipement de collecte). On peut faire des stats de trafic sur les tickets d'acct stop, dégager des comportements utilisateurs, etc.

• La gestion de déménagement d'abonné n'implique pas de changer des informations d'authentification : dans le cas du ppp, il s'agit du login qui fera foi, tandis qu'en DHCP, ce sera l'option 82 qui est lié à l'interface physique du DSLAM, OLT, ou autre qui fera foi. Donc en cas de déménagement, il faut aussi prendre en compte la nouvelle option 82. En cas de déplacement de port, etc. la gestion via PPP est beaucoup plus flexible.

• Le tunneling L2TP qui permet de très facilement concentrer la collecte de certains clients (B2B) sur des LNS dédiés ou autre.

• En PPPoE : La fragmentation liée à la MTU de 1492

• Le coût du PPP existe (on l'oublie souvent), car il faut bien collecter les clients pour leur assigner une ip (et un subnet dans le cas d'offre B2B). Il y a donc un coût financier en équipement, maintenance, humain pour gérer ces équipements, dalles, etc. Bref, ce n'est pas un coût si anodin.

• La QoS qui est anecdotique sur le PPP. On en parle depuis longtemps, mais je n'ai jamais vu un équipement de type LNS faire de la QoS qui marche ou qui lorsqu'elle fonctionne n'écroule pas les performances de la machine (on en revient au coût).

• QoS. La QoS est fonctionnelle, éprouvée et fonctionne chez TOUS les constructeurs d'équipement de collecte de ligne (DSLAM, OLT, etc.), du moins ceux auxquels j'ai pu toucher. Il n'y a rien de sorcier pour la mettre en place contrairement à l'expérimentation PPPoX qui est particulièrement lourde et qui ne fonctionne pas.

• Le coût. Là où on a des équipements de collecte (BAS, LNS), ici, nous n'avons plus rien, juste un switch qui fera relay DHCP. Là où l'on avait des radiusd, on remplace par des dhcpd. La différence de coût est grosse.

• Le coût au niveau IAD. Côté client, je pense (jamais mené de test à ce propos, mais la logique le veut) que les performances de l'équipement s'en ressentent : une encapsulation / décapsulation en moins. Et dans le cas de petits paquets arrivant à un débit important, les performances du modem peuvent s'en trouver TRÈS affecté. J'ai mené des stress test sur un certain nombre d'équipementiers modem et il est très facile de tuer un modem avec un "bon" débit en upstream et des paquets bien dimensionnés ⇒ le CPU de ce dernier atteint très vite les 100% CPU

• Aucune notion de fin de session. On n'a aucune information sur l'utilisateur et son état et ne récupérons pas d'informations sur sa connexion contrairement au Radius. Ce point peut sembler anodin, il n'en est rien. Une hotline a besoin de savoir à l'instant X si un client est connecté (et non ping n'est pas une réponse) : Un port de DSLAM peut être marqué up mais ce n'est pas pour autant que le client fonctionne. On a déjà vu des cartes de DSLAM en carafe qui refusent de laisser passer un paquet tout en restant up. Le ping n'est pas une solution, car un certain nombre de personnes bloquent le ping. Ce point de notion de session est le plus sensible à mon sens. Pour avoir une info de début de session en DHCP, il suffit d'avoir un parser de log afin d'avoir ces informations. Le point négatif du DHCP est qu'il n'y a pas d'ACCT STOP.

• La QoS qui est anecdotique sur le PPP. On en parle depuis longtemps mais je n'ai jamais vu un équipement de type LNS faire de la QoS qui marche ou qui lorsqu'elle fonctionne n'écroule pas les performances de la machine (on en revient au coût).

Free utilisait un CISCO SCE 2000 pour brider les protocoles "indésirable" selon lui.

Pour faire de la QoS, il faut connaître le débit de synchro afin de laisser passer le trafic prioritaire selon cette règle : (débit de synchro - débit du flux prioritaire - petite marge). tout ce qui dépasse ce débit est droppé (ou bufferisé). Les CISCO SCE 2000 ne peuvent donc que dégrader certains flux et pas prioriser un trafic.

Ce qui ne règle que le problème du MTU sur le lien de collecte (pour TCP); si le MTU diminue après, il faudra bien que le système gère cela correctement.