Projet

Général

Profil

ARCEP20120217 » Historique » Version 6

Version 5 (Bernard Urban, 05/02/2012 14:46) → Version 6/33 (Bernard Urban, 05/02/2012 23:34)

h1. ARCEP20120217

* Issue #129
* http://www.arcep.fr/uploads/tx_gspublication/consult-qs-acces-internet-fixe-dec2011.pdf
* http://www.arcep.fr/uploads/tx_gspublication/consult-projdec-vf-interco-neutalite-dec2011.pdf
* http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1469&tx_gsactualite_pi1[backID]=1&cHash=a1c027a224
* FFDN

h2. Liens

* http://www.pcinpact.com/news/68294-lenteurs-youtube-free-google-cogent.htm
* Draft réponse Benjamin Bayard https://fdn.quadpad.lqdn.fr/24?


TODO

h2. Eléments d'analyse pour une réponse

4: le groupe de travail restreint risque de se limiter aux gros opérateurs

6: le pourcentage d'équipements dans les classes ADSL devrait aussi
faire l'objet de mesures d'évolution dans le temps.

7: la distinction OM est pertinente, mais serait tout aussi pertinente
une distinction zones rurales/zones urbaines (donc, oui à 18). Si des
spécificités pour l'OM sont définies, elles pourraient justifier de ne
pas faire d'effort pour assurer la convergence des performances de
l'accès OM par rapport à la métropole.

13: environnement dédié: le prestataire externe n'est pas vraiment
indépendant du FAI; il est plus facile de tricher pour internet que
pour le tph. Le problème de la TV sur IP ne concerne pas les accès les
plus lents, il ne doit pas être bloquant pour avancer

15: peu d'influence du modem a priori

16: une normalisation du débit par rapport aux capacités de la ligne
ADSL simplifierait la mise en oeuvre

17: si on suit l'approche 16, le cablage interne est intégré

19: la localisation des mires ne doit pas être connue des FAI (pas
d'IP fixe); l'accès aux mires devrait se faire via
des protocoles et ports aléatoires (port 25!)

20: pourquoi se limiter au TCP? je suppose qu'il est sous-entendu
qu'on reste en ipv4, il faudrait voir plus loin

21: perte de paquets, latence: là aussi, les mesures devraient être
multiports, multiprotocoles

22: la mesure orientée usage va encourager l'optimisation des
protocoles les plus largement utilisés (http...), via des techniques
comme les caches web; d'où une boucle de rétoaction décourageant
l'utilisation d'alternatives potentiellemnet plus adaptées. Bref,
mauvaise idée.

23: oui!

24: si la sonde matérielle s'intercale entre un modem pur et un
routeur, pas de problème pour détecter si la ligne est utilisée ou
pas; dans le cas de modem qui fait routeur ou d'IPTV (donc les box),
il y a effectivement un problème pour détecter la non utilisation de
la ligne; je verrais bien un équipement prioritaire en sondes des
utilisateurs de modem purs (cas devant couvrir pas mal
d'adhérents de FFDN...)

25: pour éviter l'influence d'occupation de la ligne, on pourrai se
limiter aux périodes du petit matin

31: comme pour 13, prestataire pas vraiment indépendant, auditeur ou
pas

32: comme pour 19, la localisation des accès de mesure doivent être
inconnus des FAI

33: ok pour l'outil, avec bien sûr les bémols habituels (pas Windows
only, pas root...); voir si les outils comme grenouille.com ne font
pas déjà l'affaire

34: oui

Collecte trimestrielle

Article 1b: si cet opérateur est situé complètement à l'étranger, il
semble difficile d'exiger de leur part de fournir les informations
demandées