Wat zou transitverkeer in dit geval kosten?

Reply-To: peter.peters@utwente.nl
NNTP-Posting-Host: civ-tens022.itbe.utwente.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: netlx020.civ.utwente.nl 1105740903 1892 130.89.36.21 (14 Jan 2005 22:15:03 GMT)
X-Complaints-To: abuse@utwente.nl
NNTP-Posting-Date: Fri, 14 Jan 2005 22:15:03 +0000 (UTC)
X-Newsreader: Forte Agent 2.0/32.652
Xref: nl-news.euro.net nl.internet.providers:151838

On Fri, 14 Jan 2005 16:12:58 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:

>>En als je een goede output wil, dan moet de
>>vertraging a) binnen de perken blijven en b) nagenoeg constant zijn.
>>Beide condities zijn niet echt goed te realiseren.
>
>Dat constant houden kan je doen door te bufferen aan de ontvangende kant.
>Probleem is natuurlijk dat in de praktijk het netwerk niet meewerkt, waardoor
>je geen QoS parameters krijgt.

Maar dan haal je zeker eis a) niet meer. Want je moet dan zolang
bufferen dat je over de seconde vertraging heengaat en dan is een
gesprek niet meer te volgen.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente

In article <s1hgu0dql3v7hnit79ctjbqlv1n5a2gqs8@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Fri, 14 Jan 2005 16:12:58 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>
>>>En als je een goede output wil, dan moet de
>>>vertraging a) binnen de perken blijven en b) nagenoeg constant zijn.
>>>Beide condities zijn niet echt goed te realiseren.
>>
>>Dat constant houden kan je doen door te bufferen aan de ontvangende kant.
>>Probleem is natuurlijk dat in de praktijk het netwerk niet meewerkt, waardoor
>>je geen QoS parameters krijgt.
>
>Maar dan haal je zeker eis a) niet meer. Want je moet dan zolang
>bufferen dat je over de seconde vertraging heengaat en dan is een
>gesprek niet meer te volgen.

Ik weet hoe jij 'nagenoeg constant' defininieert, maar als een round trip
bijv. 40 ms is. (Mijn ADSL verbinding zit rond de 15 ms, dus dat twee keer,
en dan nog 10 ms voor binnen Nederland) dan kan je gemakkelijk nog eens
40 ms bufferen zonder dat het echt een groot probleem wordt.

Enige vorm van QoS moet je vrijwel altijd hebben. Maar heeft weinig met
kabel versus DSL of ATM versus IP te maken.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

In article <slrncuggs2.a7u.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>On 2005-01-14, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>
>>>En als je een goede output wil, dan moet de
>>>vertraging a) binnen de perken blijven en b) nagenoeg constant zijn.
>>>Beide condities zijn niet echt goed te realiseren.
>>
>> Dat constant houden kan je doen door te bufferen aan de ontvangende kant.
>
>Waar denk je dat de latency in VoIP vandaan komt? Zou dat, zeker bij een
>hoge latency doordat iemand anders *ook* verkeer genereert, een buffer hier
>en daar kunnen zijn? Zou VoIP zo slim kunnen zijn om afhankelijk van nominale
>en maximale latency adaptief te bufferen? Zodat de delay door de
>playout-buffers toeneemt op het moment dat de kwaliteit van de verbinding
>afneemt? Zou dat niet zijn wat ik een paar postings terug beweerde?

Ja, maar je zet het voice verkeer natuurlijk in een priority queue. En
dan heb je maximaal 1 full-length frame pech.

>> je geen QoS parameters krijgt.
>
>http://www.networkmagazine.com/share...cleID=16600121
>
>"DSL and QoS. Two things that don't usually go together."

"The pain point is lack of IP intelligence between the DSL Access
"Multiplexer (DSLAM) and the Customer Premises Equipment (CPE),
"where congestion, latency, and packet loss lead to inaccurate
"prioritization of packets.

Hier ben ik maar gestopt met lezen. Ik weet niet wat die auteur gerookt
heeft, maar geholpen heeft het niet.

Als je graag met ATM wil spelen, ga gerust je gang. Maar houdt er rekening
mee dat bij ongeveer 10 Mbit/s simpele hacks er voor kunnen zorgen dat
voice verkeer over IP in 99.9% van de gevallen gewoon werkt. En dan krijg
je dus de situatie dat korte gesprekken toch al over GSM gaan, dat low budget
Internet gesprekken natuurlijk helemaal niets mogen kosten. En dan heb je
nog een KPN met (waarschijnlijk) vrijwel afgeschreven POTS en ISDN
centrales.

Verder zullen bedrijven natuurlijk niet snel een interne ATM backbone aan
gaan leggen. Dus komt er een markt voor 'ethernet' telefoons die zowel voor
grote bedrijven als voor particulieren interessant is, en een markt voor ATM
telefoons die maar voor een heel kleine groep echt interessant is.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

Reply-To: ruben-news@nutz.nl
NNTP-Posting-Host: its.blacklisted.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF8
Content-Transfer-Encoding: 7bit
X-Trace: nl-news.euro.net 1105795995 14991 213.239.176.42 (15 Jan 2005 13:33:15 GMT)
X-Complaints-To: usenet@nl-news.euro.net
NNTP-Posting-Date: Sat, 15 Jan 2005 13:33:15 +0000 (UTC)
Cancel-Lock: sha1:6i3tYqmCV98tj/keZSOBKOk3mqY= sha1:FheRn0MdX//UMEkkdmdQub8a9dc=
X-No-Archive: Yes
User-Agent: slrn/0.9.8.0 (Linux)
Xref: nl-news.euro.net nl.internet.providers:151845

On 2005-01-15, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:

>>Waar denk je dat de latency in VoIP vandaan komt? Zou dat, zeker bij een
>>hoge latency doordat iemand anders *ook* verkeer genereert, een buffer hier
>>en daar kunnen zijn?

> Ja, maar je zet het voice verkeer natuurlijk in een priority queue. En
> dan heb je maximaal 1 full-length frame pech.

Combineer dit nu eens met het volgende stukje:

> "The pain point is lack of IP intelligence between the DSL Access
> "Multiplexer (DSLAM) and the Customer Premises Equipment (CPE),
> "where congestion, latency, and packet loss lead to inaccurate
> "prioritization of packets.

DSL of kabel? Geen FUCKING QOS TE BEKENNEN. Tja. Daar zit je met je mooie
oplossing. DSL-lijntje erbij, enkel voor VoIP? Of in zee gaan met een
DSL-provider die je op een 1:20 business-lijn ook nog een 1:1 kanaal voor
voice kan leveren? Die dat dan via meegeleverde modems voor je aflevert op
een koppelvlak waar je bestaande centrale zo aan kan? Zodat niet iedereen
een cisco-telefoon van 700 euro op z'n bureau moet hebben?

> Hier ben ik maar gestopt met lezen. Ik weet niet wat die auteur gerookt
> heeft, maar geholpen heeft het niet.

Hij heeft gelezen, niet gerookt. In de releasenotes van de software van
routers en DSLAM's, bijvoorbeeld. QoS zit in Cisco-DSLAM's, maar staat
standaard uit. Zonder is al genoeg ellende. Alcatel wil je eerst andere
hardware verkopen. Tegen de tijd dat iedereen op een ADSL2-kaart zit zal QoS
misschien eens wat worden. Als ik kijk naar het 'tempo' waarin ADSL2
uitgerold wordt: na 2007 of 2008 ofzo. Net zoiets als IPv6. De hardware kan
het niet. De software wil het voor je emuleren, maar die benadering is 'less
than perfect'.

> Maar houdt er rekening mee dat bij ongeveer 10 Mbit/s simpele hacks er
> voor kunnen zorgen dat voice verkeer over IP in 99.9% van de gevallen
> gewoon werkt.

99.9% is overschat. Op de 'echte' IP VoIP-netwerken die ik ken (en dat zijn
er wel een paar) gaat tegenwoordig, na jaren schaven en tunen 40-60% van de
gesprekken zonder fouten. De resterende helft laat ergens in het pad
foutmeldingen achter over latency, te laat aangekomen packets of leeggelopen
buffers. Gebruikers zijn inmiddels wel gewend aan de echo's, de haperingen
en het moeten herhalen van delen van zinnen. Logfiles liegen niet.

En hoeveel bedrijven hebben budget voor links van 10Mbit of meer tussen
vestigingen? Zeker als anderen even afdoende oplossingen kunnen leveren voor
een paar tientjes per vestiging? Zat rekenvoorbeelden bij offertes gezien
waarin de besparingen zo groot waren dat ze in de eerste drie maanden de
volledige investering terugverdienden. Kijk. Dat is besparen.

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

In article <slrncui6sr.8mp.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>On 2005-01-15, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>> Hier ben ik maar gestopt met lezen. Ik weet niet wat die auteur gerookt
>> heeft, maar geholpen heeft het niet.
>
>Hij heeft gelezen, niet gerookt. In de releasenotes van de software van
>routers en DSLAM's, bijvoorbeeld. QoS zit in Cisco-DSLAM's, maar staat
>standaard uit. Zonder is al genoeg ellende. Alcatel wil je eerst andere
>hardware verkopen. Tegen de tijd dat iedereen op een ADSL2-kaart zit zal QoS
>misschien eens wat worden. Als ik kijk naar het 'tempo' waarin ADSL2
>uitgerold wordt: na 2007 of 2008 ofzo. Net zoiets als IPv6. De hardware kan
>het niet. De software wil het voor je emuleren, maar die benadering is 'less
>than perfect'.

Dus Versatel zit gewoon te zeuren dat de KPN de zaak vertraagt. Zij
willen helemaal niet medio dit jaar ADSL2(+) draaiend hebben.

Bij Cisco zijn ze denk ik handig genoeg om wat simpele QoS hacks toe te
voegen die wel werken. Maar moet natuurlijk wel vraag naar zijn.

Als een paar grote spelers besluiten om IP multicast te doen, en daarom ook
VoIP (en er is voldoende bandbreedte, wat op dit moment met populaire
1 Mbit/s downstream varianten nog wel eens een probleem zou kunnen zijn)
dan zal er wel vraag komen naar simpele hacks die gewoon werken.

>En hoeveel bedrijven hebben budget voor links van 10Mbit of meer tussen
>vestigingen?

Dat hangt er vanaf hoe snel dat goedkoper wordt. Op dit moment kost
8/1 bijna niets omdat het erg populair is. ADSL2(+) zal wel dezelfde kant
op gaan. Een en ander is natuurlijk afhankelijk van de groei in backbone
capaciteit.

Upstream is voornamelijk een kwestie van wat simpele QoS hacks in een ADSL
router.

>Zat rekenvoorbeelden bij offertes gezien
>waarin de besparingen zo groot waren dat ze in de eerste drie maanden de
>volledige investering terugverdienden. Kijk. Dat is besparen.

Vooral doen dan.



--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

On 2005-01-15, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:

> Dus Versatel zit gewoon te zeuren dat de KPN de zaak vertraagt. Zij
> willen helemaal niet medio dit jaar ADSL2(+) draaiend hebben.

BBNed levert het gewoon, maar met de aantekening dat het een test is, en dat
de beheerder van het telefoonnet kan besluiten geen ADSL2 toe te laten.

> Bij Cisco zijn ze denk ik handig genoeg om wat simpele QoS hacks toe te
> voegen die wel werken. Maar moet natuurlijk wel vraag naar zijn.

Cisco ontwikkelt niet meer aan z'n DSL-platform. Enkel nog bugfixes. Een van
de redenen dat alle grote providers Cisco volledig gedumpt heeft.

> Als een paar grote spelers besluiten om IP multicast te doen, en daarom ook
> VoIP (en er is voldoende bandbreedte, wat op dit moment met populaire
> 1 Mbit/s downstream varianten nog wel eens een probleem zou kunnen zijn)
> dan zal er wel vraag komen naar simpele hacks die gewoon werken.

Er hoeven geen hacks toegepast te worden voor multicast. Die 'technologie'
is zo oud dat het gewoon werkt. Niemand in Nederland gebruikt het, maar de
apparatuur, alle apparatuur, kan het zonder noemenswaardige problemen. Zelfs
windows heeft een afdoende IGMP-implementatie. Die desalniettemin de nodige
bugs zal blijken te hebben. En een virus is eng, maar een virus via
multicast is *ENGER*.

>>En hoeveel bedrijven hebben budget voor links van 10Mbit of meer tussen
>>vestigingen?

> Dat hangt er vanaf hoe snel dat goedkoper wordt. Op dit moment kost
> 8/1 bijna niets omdat het erg populair is. ADSL2(+) zal wel dezelfde kant
> op gaan. Een en ander is natuurlijk afhankelijk van de groei in backbone
> capaciteit.

ADSL2 bied nagenoeg geen voordelen qua snelheden, met twee uitzonderingen.
Mensen die extreem dicht bij een centrale wonen kunnen een hogere snelheid
halen, maar ten koste van iedereen die verder zit. En mensen aan de rand van
het huidige gebied kunnen opeens wel bruikbare snelheden krijgen (dus
512/256 ofzo) zolang men die 24Mbit-klanten uit het spectrum weet te houden.
ADSL2+ verlegt de grens voor 256/256 van 5500 meter naar 7500 meter. Feest
voor de mensen op het platteland.

> Upstream is voornamelijk een kwestie van wat simpele QoS hacks in een ADSL
> router.

Die negeren we maar even.

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

On Sat, 15 Jan 2005 13:27:06 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:

>>Maar dan haal je zeker eis a) niet meer. Want je moet dan zolang
>>bufferen dat je over de seconde vertraging heengaat en dan is een
>>gesprek niet meer te volgen.
>
>Ik weet hoe jij 'nagenoeg constant' defininieert, maar als een round trip
>bijv. 40 ms is. (Mijn ADSL verbinding zit rond de 15 ms, dus dat twee keer,
>en dan nog 10 ms voor binnen Nederland) dan kan je gemakkelijk nog eens
>40 ms bufferen zonder dat het echt een groot probleem wordt.

Dat is onder rustige condities. Die round trip dondert in elkaar als
iemand windows (of een ander OS) update draait.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente

In article <punku0doaum8ma3hb2r0278refitut4p3h@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Sat, 15 Jan 2005 13:27:06 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>
>>>Maar dan haal je zeker eis a) niet meer. Want je moet dan zolang
>>>bufferen dat je over de seconde vertraging heengaat en dan is een
>>>gesprek niet meer te volgen.
>>
>>Ik weet hoe jij 'nagenoeg constant' defininieert, maar als een round trip
>>bijv. 40 ms is. (Mijn ADSL verbinding zit rond de 15 ms, dus dat twee keer,
>>en dan nog 10 ms voor binnen Nederland) dan kan je gemakkelijk nog eens
>>40 ms bufferen zonder dat het echt een groot probleem wordt.
>
>Dat is onder rustige condities. Die round trip dondert in elkaar als
>iemand windows (of een ander OS) update draait.

Als de overbelasting het gevolg is van TCP connecties, dan zou je aan de
CPE kant met traffic shaping de queue bij de access concentrator weg
kunnen halen.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

In article <slrncujedq.ua5.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>On 2005-01-15, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>> Als een paar grote spelers besluiten om IP multicast te doen, en daarom ook
>> VoIP (en er is voldoende bandbreedte, wat op dit moment met populaire
>> 1 Mbit/s downstream varianten nog wel eens een probleem zou kunnen zijn)
>> dan zal er wel vraag komen naar simpele hacks die gewoon werken.
>
>Er hoeven geen hacks toegepast te worden voor multicast.

Als je IP multicast wil doen zonder ATM multicast dan zal je IP routers
vlak naast de DSLAMs moeten zetten. En dan zal je er ook nog voor moeten
zorgen (als telco) dat als je meerdere ISPs als klant hebt, je alle PIM
traffic netjes verdeelt over die ISPs (tenzij alleen de telco iets
met multicast gaat doen).

Maar het gaat erom, dat als je 'definitief' geen ATM meer gaat doen, het
logisch wordt om te zorgen dan je IP routers ook fatsoenlijk VoIP kunnen
doen (tenmiste als het er naar uitziet dat je concurrenten van VoDSL een
succes weten te maken; als het niet het geval dan is het handiger om dat
hele telefonie gebeuren te laten zoals het is).

>Die 'technologie'
>is zo oud dat het gewoon werkt. Niemand in Nederland gebruikt het, maar de
>apparatuur, alle apparatuur, kan het zonder noemenswaardige problemen.

Dat valt nog wel eens tegen.


--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

On Sun, 16 Jan 2005 15:52:00 +0100, Jochem van Dieten
<nomail@devnull.invalid> wrote:

>> Er hoeven geen hacks toegepast te worden voor multicast. Die 'technologie'
>> is zo oud dat het gewoon werkt. Niemand in Nederland gebruikt het, maar de
>> apparatuur, alle apparatuur, kan het zonder noemenswaardige problemen. Zelfs
>> windows heeft een afdoende IGMP-implementatie. Die desalniettemin de nodige
>> bugs zal blijken te hebben. En een virus is eng, maar een virus via
>> multicast is *ENGER*.
>
>In januari vorig jaar hebben we de eerste problemen daarmee al
2001
>gezien. Toen was er een virus dat ook 224/4 af ging scannen en
Ramen

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente