Je ne suis pas spécialiste, mais voila comment je le comprends :
Jusqu'à un certain point de dépassement, celui qui reçoit le traffic
peut le
stocker pour le ré-émettre quand le débit présenté repasse en dessous de son
maxi prévu (il reste alors du débit disponible).
C'est une règle de QoS qui permet d'écouler une pointe de traffic
pour une
classe de traffic
qui le supporte (pas de temps réel ni d'isochrone, pas de
VoIP ou de TV ou vidéo conférence pas exemple).
Je ne suis pas spécialiste, mais voila comment je le comprends :
Jusqu'à un certain point de dépassement, celui qui reçoit le traffic
peut le
stocker pour le ré-émettre quand le débit présenté repasse en dessous de son
maxi prévu (il reste alors du débit disponible).
C'est une règle de QoS qui permet d'écouler une pointe de traffic
pour une
classe de traffic
qui le supporte (pas de temps réel ni d'isochrone, pas de
VoIP ou de TV ou vidéo conférence pas exemple).
Je ne suis pas spécialiste, mais voila comment je le comprends :
Jusqu'à un certain point de dépassement, celui qui reçoit le traffic
peut le
stocker pour le ré-émettre quand le débit présenté repasse en dessous de son
maxi prévu (il reste alors du débit disponible).
C'est une règle de QoS qui permet d'écouler une pointe de traffic
pour une
classe de traffic
qui le supporte (pas de temps réel ni d'isochrone, pas de
VoIP ou de TV ou vidéo conférence pas exemple).
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
Didier avait écrit le 27/06/2008 :
Je ne suis pas spécialiste, mais voila comment je le comprends :
merciJusqu'à un certain point de dépassement, celui qui reçoit le traffic
qui entends-tu comme "receveur de trafic"?peut le stocker pour le ré-émettre quand le débit présenté repasse en
dessous de son maxi prévu (il reste alors du débit disponible).
je le comprends comme ça - si je me trompe, merci de corriger:
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
j'ai bon ou j'ai rien compris?C'est une règle de QoS qui permet d'écouler une pointe de traffic
de toute façon il est clair que un dépassement de BP contractuel, ça
soit censuré, le tout est de savoir comment ça s'applique(rait) et si
c'est justigié, et qui l'effectue (le FAI ou l'ope national)pour une classe de traffic
donc des ports ou classe de portsqui le supporte (pas de temps réel ni d'isochrone, pas de VoIP ou de
TV ou vidéo conférence pas exemple).
VoIP aussi?????? ouhlaaa
mais ça bouffe rien du tout la VoIP.... 64 kbs , c'est pas ça qui fait
déborder la bande pasante
à moins que ce ne soit une mesure de rétorsion pour obliger le FAI à
payer plus de BP...
je nage - sincèrement, je comprendrais que si la BP prévue est dépassée,
FT bloque les ports de téléchargement (qui sont parfois dans la même
classe de ports que les jeux online)
à moins que ce ne soit réellement des mesures de rétorsion?
je nage
Didier avait écrit le 27/06/2008 :
Je ne suis pas spécialiste, mais voila comment je le comprends :
merci
Jusqu'à un certain point de dépassement, celui qui reçoit le traffic
qui entends-tu comme "receveur de trafic"?
peut le stocker pour le ré-émettre quand le débit présenté repasse en
dessous de son maxi prévu (il reste alors du débit disponible).
je le comprends comme ça - si je me trompe, merci de corriger:
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
j'ai bon ou j'ai rien compris?
C'est une règle de QoS qui permet d'écouler une pointe de traffic
de toute façon il est clair que un dépassement de BP contractuel, ça
soit censuré, le tout est de savoir comment ça s'applique(rait) et si
c'est justigié, et qui l'effectue (le FAI ou l'ope national)
pour une classe de traffic
donc des ports ou classe de ports
qui le supporte (pas de temps réel ni d'isochrone, pas de VoIP ou de
TV ou vidéo conférence pas exemple).
VoIP aussi?????? ouhlaaa
mais ça bouffe rien du tout la VoIP.... 64 kbs , c'est pas ça qui fait
déborder la bande pasante
à moins que ce ne soit une mesure de rétorsion pour obliger le FAI à
payer plus de BP...
je nage - sincèrement, je comprendrais que si la BP prévue est dépassée,
FT bloque les ports de téléchargement (qui sont parfois dans la même
classe de ports que les jeux online)
à moins que ce ne soit réellement des mesures de rétorsion?
je nage
Didier avait écrit le 27/06/2008 :
Je ne suis pas spécialiste, mais voila comment je le comprends :
merciJusqu'à un certain point de dépassement, celui qui reçoit le traffic
qui entends-tu comme "receveur de trafic"?peut le stocker pour le ré-émettre quand le débit présenté repasse en
dessous de son maxi prévu (il reste alors du débit disponible).
je le comprends comme ça - si je me trompe, merci de corriger:
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de téléchargement
j'ai bon ou j'ai rien compris?C'est une règle de QoS qui permet d'écouler une pointe de traffic
de toute façon il est clair que un dépassement de BP contractuel, ça
soit censuré, le tout est de savoir comment ça s'applique(rait) et si
c'est justigié, et qui l'effectue (le FAI ou l'ope national)pour une classe de traffic
donc des ports ou classe de portsqui le supporte (pas de temps réel ni d'isochrone, pas de VoIP ou de
TV ou vidéo conférence pas exemple).
VoIP aussi?????? ouhlaaa
mais ça bouffe rien du tout la VoIP.... 64 kbs , c'est pas ça qui fait
déborder la bande pasante
à moins que ce ne soit une mesure de rétorsion pour obliger le FAI à
payer plus de BP...
je nage - sincèrement, je comprendrais que si la BP prévue est dépassée,
FT bloque les ports de téléchargement (qui sont parfois dans la même
classe de ports que les jeux online)
à moins que ce ne soit réellement des mesures de rétorsion?
je nage
Jil S a écrit :
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de
téléchargement
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Jil S a écrit :
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de
téléchargement
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Jil S a écrit :
en ipadsl, FT peut bloquer (stocker) le débit quand il dépasse les
limites prévues contractuellement, soit en totalité, soit par
applications/ports très dépensiers de BP, comme les ports de
téléchargement
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Bon, disons que FT reçoit du traffic de Free, et qu'ils ont passé un contrat
(SLA Service Level Agreement) du genre :
* débit nominal 2 gigabit/s
* débit crête 2,1 gigabit/s, pendant max 1 seconde, qui ne sera ni lissé ni
écrêté.
* au delà, autorisation de lisser si le traffic appartient à une classe de
traffic (la définition de cette classe peut reposer sur différents critères,
comme le type de protocole transporté, la valeur du champ DSCP de la trame
IP, etc ...).
* autorisation d'écrêter si le traffic appartient à une autre classe de
traffic.
Le contrat va donc spécifier aussi la définition des deux classes concernées
par le dispositif (qu'on appelle Traffic Shaping, mise en forme du traffic).
On peut baser la définition d'une classe sur un port TCP ou UDP, mais en
principe le transporteur qui reçoit le traffic à écouler (FT dans notre cas)
s'en fout un peu. J'imagine que c'est plutôt le client (Free ici) qui choisit
le type de traffic qu'il peut "sacrifier".
Donc, même si la VoIP consomme peu de débit, le traffic shaping pourrait de
manière un peu aveugle (selon les définitions des classes) écrêter des
paquets appartenant à un flux VoIP. Ce qui serait dommage.
Pour terminer, ce qui fait déborder du débit contractuel, ce sont les
derniers kbit/s, même s'ils ne sont pas nombreux (la fameuse goutte d'eau qui
met le feu aux poudres, ou l'étincelle qui fait déborder le vase ;-)))
ps : ne pas parler de bande passante; ce terme définit la capacité d'un
support en écoulement de traffic. C'est la capacité disponible sur ce
support, pas ce qu'on lui demande d'écouler.
Bon, disons que FT reçoit du traffic de Free, et qu'ils ont passé un contrat
(SLA Service Level Agreement) du genre :
* débit nominal 2 gigabit/s
* débit crête 2,1 gigabit/s, pendant max 1 seconde, qui ne sera ni lissé ni
écrêté.
* au delà, autorisation de lisser si le traffic appartient à une classe de
traffic (la définition de cette classe peut reposer sur différents critères,
comme le type de protocole transporté, la valeur du champ DSCP de la trame
IP, etc ...).
* autorisation d'écrêter si le traffic appartient à une autre classe de
traffic.
Le contrat va donc spécifier aussi la définition des deux classes concernées
par le dispositif (qu'on appelle Traffic Shaping, mise en forme du traffic).
On peut baser la définition d'une classe sur un port TCP ou UDP, mais en
principe le transporteur qui reçoit le traffic à écouler (FT dans notre cas)
s'en fout un peu. J'imagine que c'est plutôt le client (Free ici) qui choisit
le type de traffic qu'il peut "sacrifier".
Donc, même si la VoIP consomme peu de débit, le traffic shaping pourrait de
manière un peu aveugle (selon les définitions des classes) écrêter des
paquets appartenant à un flux VoIP. Ce qui serait dommage.
Pour terminer, ce qui fait déborder du débit contractuel, ce sont les
derniers kbit/s, même s'ils ne sont pas nombreux (la fameuse goutte d'eau qui
met le feu aux poudres, ou l'étincelle qui fait déborder le vase ;-)))
ps : ne pas parler de bande passante; ce terme définit la capacité d'un
support en écoulement de traffic. C'est la capacité disponible sur ce
support, pas ce qu'on lui demande d'écouler.
Bon, disons que FT reçoit du traffic de Free, et qu'ils ont passé un contrat
(SLA Service Level Agreement) du genre :
* débit nominal 2 gigabit/s
* débit crête 2,1 gigabit/s, pendant max 1 seconde, qui ne sera ni lissé ni
écrêté.
* au delà, autorisation de lisser si le traffic appartient à une classe de
traffic (la définition de cette classe peut reposer sur différents critères,
comme le type de protocole transporté, la valeur du champ DSCP de la trame
IP, etc ...).
* autorisation d'écrêter si le traffic appartient à une autre classe de
traffic.
Le contrat va donc spécifier aussi la définition des deux classes concernées
par le dispositif (qu'on appelle Traffic Shaping, mise en forme du traffic).
On peut baser la définition d'une classe sur un port TCP ou UDP, mais en
principe le transporteur qui reçoit le traffic à écouler (FT dans notre cas)
s'en fout un peu. J'imagine que c'est plutôt le client (Free ici) qui choisit
le type de traffic qu'il peut "sacrifier".
Donc, même si la VoIP consomme peu de débit, le traffic shaping pourrait de
manière un peu aveugle (selon les définitions des classes) écrêter des
paquets appartenant à un flux VoIP. Ce qui serait dommage.
Pour terminer, ce qui fait déborder du débit contractuel, ce sont les
derniers kbit/s, même s'ils ne sont pas nombreux (la fameuse goutte d'eau qui
met le feu aux poudres, ou l'étincelle qui fait déborder le vase ;-)))
ps : ne pas parler de bande passante; ce terme définit la capacité d'un
support en écoulement de traffic. C'est la capacité disponible sur ce
support, pas ce qu'on lui demande d'écouler.
Jil S a écrit :
si c'était un pb de collecte sous dimensionné, j'aimerais savoir
comment FT décide d'effectuer la "mesure de rétorsion"?
Quelle mesure de rétorsion ?
Si Free achète x Mbit/s de collecte, FT livre x Mbit/s. Si les abonnés
demandent plus, il y aura des paquets perdus.
Jil S a écrit :
si c'était un pb de collecte sous dimensionné, j'aimerais savoir
comment FT décide d'effectuer la "mesure de rétorsion"?
Quelle mesure de rétorsion ?
Si Free achète x Mbit/s de collecte, FT livre x Mbit/s. Si les abonnés
demandent plus, il y aura des paquets perdus.
Jil S a écrit :
si c'était un pb de collecte sous dimensionné, j'aimerais savoir
comment FT décide d'effectuer la "mesure de rétorsion"?
Quelle mesure de rétorsion ?
Si Free achète x Mbit/s de collecte, FT livre x Mbit/s. Si les abonnés
demandent plus, il y aura des paquets perdus.
Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant le
BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant le
BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que des
tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP des
abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant le
BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Didier avait soumis l'idée :
Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des classes)
écrêter des paquets appartenant à un flux VoIP. Ce qui serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
y aurait même des lignes free ipadsl qui auraient tenu le 8 Mbs pendant
plusieurs années et qui deviennent impossibles à faire fonctionner par
FT autrement qu'en 2 Mbs - comment est-ce possible?
(no polémique dans ma question)
Didier avait soumis l'idée :
Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des classes)
écrêter des paquets appartenant à un flux VoIP. Ce qui serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
y aurait même des lignes free ipadsl qui auraient tenu le 8 Mbs pendant
plusieurs années et qui deviennent impossibles à faire fonctionner par
FT autrement qu'en 2 Mbs - comment est-ce possible?
(no polémique dans ma question)
Didier avait soumis l'idée :
Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des classes)
écrêter des paquets appartenant à un flux VoIP. Ce qui serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
y aurait même des lignes free ipadsl qui auraient tenu le 8 Mbs pendant
plusieurs années et qui deviennent impossibles à faire fonctionner par
FT autrement qu'en 2 Mbs - comment est-ce possible?
(no polémique dans ma question)
Didier a écrit :Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que
des tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP
des abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant
le BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Quel routeur de bordure ? Celui qui livre la collecte IP/ADSL au FAI ?
C'est pareil, il ne voit que les tunnels L2TP, pas le trafic IP des
abonnés qui est encapsulé dedans. Et je ne vois pas de quel droit il se
permettrait de faire du shaping sur le contenu de ces tunnels.
Didier a écrit :
Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que
des tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP
des abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant
le BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Quel routeur de bordure ? Celui qui livre la collecte IP/ADSL au FAI ?
C'est pareil, il ne voit que les tunnels L2TP, pas le trafic IP des
abonnés qui est encapsulé dedans. Et je ne vois pas de quel droit il se
permettrait de faire du shaping sur le contenu de ces tunnels.
Didier a écrit :Pascal Hambourg a écrit :
Ça ne marche pas comme ça. Le réseau de collecte de FT ne voit que
des tunnels L2TP entre ses BAS et les LNS des FAI, pas le trafic IP
des abonnés du FAI.
Oui, mais le routeur de bordure du réseau de FT se trouve bien avant
le BAS, et il va avoir des décisions à prendre quant à l'écoulement du
traffic apporté par le FAI -> traffic shaping.
Quel routeur de bordure ? Celui qui livre la collecte IP/ADSL au FAI ?
C'est pareil, il ne voit que les tunnels L2TP, pas le trafic IP des
abonnés qui est encapsulé dedans. Et je ne vois pas de quel droit il se
permettrait de faire du shaping sur le contenu de ces tunnels.
Jil S a écrit :Didier avait soumis l'idée :Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des
classes) écrêter des paquets appartenant à un flux VoIP. Ce qui
serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Non, pas de pb, car Free met la priorité sur les paquets VoIP plus haute
que celle sur les paquets http par exemple, et ce sont ces derniers qui
sont écrêtés.
Je prenais jus te l'exemple pour dire que ce n'est pas parce qu'un
paquet "est" de la VoIP qu'il est prioritaire et non écrêté, c'est parce
qu'il a été marqué ainsi.
Donc très logiquement ce n'est pas la VoIP qui est écrêtée, parcequ'elle
est marquée très prioritaire.Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
Oui, un NRA non fibré est en général raccordé au coeur de réseau (chez
FT) par un ensemble de liens à 2 Mbit/s (de deux à 4 je crois).
Juste faire attention que ce n'est pas parce qu'un NRA n'est pas
raccordé par une fibre, qu'il est raccordé par à 2 Mbit/s; il est
raccordé par plusieurs liens de ce type (mais c'est bien sûr très
inférieur à la capacité d'un lien sur fibre).
Jil S a écrit :
Didier avait soumis l'idée :
Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des
classes) écrêter des paquets appartenant à un flux VoIP. Ce qui
serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Non, pas de pb, car Free met la priorité sur les paquets VoIP plus haute
que celle sur les paquets http par exemple, et ce sont ces derniers qui
sont écrêtés.
Je prenais jus te l'exemple pour dire que ce n'est pas parce qu'un
paquet "est" de la VoIP qu'il est prioritaire et non écrêté, c'est parce
qu'il a été marqué ainsi.
Donc très logiquement ce n'est pas la VoIP qui est écrêtée, parcequ'elle
est marquée très prioritaire.
Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
Oui, un NRA non fibré est en général raccordé au coeur de réseau (chez
FT) par un ensemble de liens à 2 Mbit/s (de deux à 4 je crois).
Juste faire attention que ce n'est pas parce qu'un NRA n'est pas
raccordé par une fibre, qu'il est raccordé par à 2 Mbit/s; il est
raccordé par plusieurs liens de ce type (mais c'est bien sûr très
inférieur à la capacité d'un lien sur fibre).
Jil S a écrit :Didier avait soumis l'idée :Donc, même si la VoIP consomme peu de débit, le traffic shaping
pourrait de manière un peu aveugle (selon les définitions des
classes) écrêter des paquets appartenant à un flux VoIP. Ce qui
serait dommage.
Sans vouloir te critiquer - au contraire je te suis reconnaissant -
concernant la voip ça me semble moins crédible étant donné que free a
toujours annoncé qu'elle était prioritaire sur le reste
d'ailleurs une ligne à 100 ou 125 kbs - avec suffisament de débit up -
pôurra être utilisée pour la VoIP free
sur cet exemple j'ai un gros doute
Non, pas de pb, car Free met la priorité sur les paquets VoIP plus haute
que celle sur les paquets http par exemple, et ce sont ces derniers qui
sont écrêtés.
Je prenais jus te l'exemple pour dire que ce n'est pas parce qu'un
paquet "est" de la VoIP qu'il est prioritaire et non écrêté, c'est parce
qu'il a été marqué ainsi.
Donc très logiquement ce n'est pas la VoIP qui est écrêtée, parcequ'elle
est marquée très prioritaire.Par ailleurs, est-il possible que vu l'explosion de la demande adsl du
public, certrains NRA non fibrés soient débordés en terme de capacité
de débit au niveau région?
moi j'ai l'impression que oui, mais je suppute
mes potes me disent: comment c'est possible qu'une ligne eligible à 10
Mbs ne tienne finalement la synchro qu'en 2 Mbs, même si elle ne fait
que 1.5 km de long? en ipadsl toujours bien sûr
Oui, un NRA non fibré est en général raccordé au coeur de réseau (chez
FT) par un ensemble de liens à 2 Mbit/s (de deux à 4 je crois).
Juste faire attention que ce n'est pas parce qu'un NRA n'est pas
raccordé par une fibre, qu'il est raccordé par à 2 Mbit/s; il est
raccordé par plusieurs liens de ce type (mais c'est bien sûr très
inférieur à la capacité d'un lien sur fibre).
