Onderwerp: Wat zou transitverkeer in dit geval kosten?

Peter Peters wrote:

> On Mon, 10 Jan 2005 14:13:26 +0000 (UTC), Ruben van der Leij
> <ruben-news@nutz.nl> wrote:
>
>
>>>Waarom wil je ATM in plaats van IP?
>>
>>Omdat ik niet graag dezelfde blunder bega als KPN met z'n mickeystream. Als
>>je met garanties over overbooking gaat gooien moet je ze ook waar kunnen
>>maken. KPN heeft niet voor niets Epacity verzonnen.
>
>
> Versatel (?) geeft aan alles weer om te gaan bouwen naar IP vanwege hun
> doelstelling om video te kunnen gaan streamen/multicasten.

Was babyxl/tiscali niet ook bezig over te stappen op UTStarcom (IP) DSLAMs?


--
Adriaan

Adriaan wrote:
> Peter Peters wrote:
>> On Mon, 10 Jan 2005 14:13:26 +0000 (UTC), Ruben van der Leij wrote:
>>>
>>> Omdat ik niet graag dezelfde blunder bega als KPN met z'n mickeystream. Als
>>> je met garanties over overbooking gaat gooien moet je ze ook waar kunnen
>>> maken. KPN heeft niet voor niets Epacity verzonnen.
>>
>> Versatel (?) geeft aan alles weer om te gaan bouwen naar IP vanwege hun
>> doelstelling om video te kunnen gaan streamen/multicasten.
>
> Was babyxl/tiscali niet ook bezig over te stappen op UTStarcom (IP) DSLAMs?

Ja. Het grootste deel van hun netwerk is inmiddels om.

Jochem

In article <pd47u05trva5ool8v8t8n5ims5m7aalkkd@4ax.com>, Peter Peters wrote:
> On 10 Jan 2005 21:32:14 GMT, Hans Spaans <me@usenet2005.hansspaans.nl>
> wrote:
>
>>Welk onderdeel van deze header behoeft uitleg ;-)
>>
>>X-Include: <humor.h>,<troll.h>,<sarcasme.h>
>
> Het onderdeel dat ik niet zie in mijn client zonder h in te drukken. ;-)

Gebruik dan ook een echte client ;-)

Hans

--
Nihilist paradox:
`If truth does not exist, the statement "truth does not exist" is a
truth, thereby proving itself incorrect.'

On 2005-01-11, Peter Peters <P.G.M.Peters@nospam.utwente.net> wrote:

>>>>Misschien moet internetverkeer maar door de overheid worden beheerd,
>>>>geen commerciele BMW-directeurtjes enzo.

>>> Ik ken een directeur van een ISP die rijdt niet in een BMW. Die rijdt in
>>> een Matiz (van de zaak). Alleen als ze wat verder weg moet, leent ze
>>> mijn (prive) auto.

>>Patser!

> Ken je mijn auto?

> Het is niet het soort auto waarvan er in Enschede en omgeving 50% van de
> Nederlandse hoeveelheid rondrijden.

http://its.blacklisted.nl/~ruben/daf-126-2.jpg ? Dan weet ik de andere
namelijk te vinden. :P

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

"Ruben van der Leij" <ruben-news@nutz.nl> wrote in message
news:slrncu61ei.ce6.ruben-news@its.blacklisted.nl...
> On 2005-01-10, Peter Peters <P.G.M.Peters@nospam.utwente.net> wrote:
>
>>>> Waarom wil je ATM in plaats van IP?
>
>>>Omdat ik niet graag dezelfde blunder bega als KPN met z'n mickeystream. Als
>>>je met garanties over overbooking gaat gooien moet je ze ook waar kunnen
>>>maken. KPN heeft niet voor niets Epacity verzonnen.

ADSL van KPN is een aardig stabiel product, dat wat vroeger wel anders met
het SSG Dashboard, C-Nat en 6400 UAC's waar eindgebruikers op getermineerd
waren

>> Versatel (?) geeft aan alles weer om te gaan bouwen naar IP vanwege hun
>> doelstelling om video te kunnen gaan streamen/multicasten.
>
> Da's leuk. Geen 1:1 DSL van versatel, dus. Je kunt namelijk geen 1:1
> garanderen over een IP-distributielaag. Zo goed is QoS ook weer niet.
>
> Blijkbaar heeft iemand zitten suffen. Multicast op ATM is niet
> noemenswaardig anders dan op IP, en bied je zelfs meer mogelijkheiden dan op
> IP. Zoals aparte PVC's voor telefonie, data en multicast, zodat je telefoon
> ongehapert doorgaat, ondanks een streamende collega.

Allemaal leuk en aardig, maar het provisionen van ATM crossconnects vanaf
een ATM switch naar een DSLAM is een administratieve hel, zeker als je
je DSLAM's gaat subtenden. En dat voor vele honderduizenden eindgebruikers.
Een foutieve crossconnect op een ATM switch en je bent je hele dag bezig met
het nalopen van alle crossconnects...

Dat is nou het leuke van ethernet, simpelweg wat vlan-netjes trekken, vpn's
op een IP DSLAM aanmaken en het werkt.

--
Ashwin

On 2005-01-12, ashwin <straight@outta-rotterdam.nl> wrote:

>>>>Omdat ik niet graag dezelfde blunder bega als KPN met z'n mickeystream. Als
>>>>je met garanties over overbooking gaat gooien moet je ze ook waar kunnen
>>>>maken. KPN heeft niet voor niets Epacity verzonnen.

> ADSL van KPN is een aardig stabiel product, dat wat vroeger wel anders met
> het SSG Dashboard, C-Nat en 6400 UAC's waar eindgebruikers op getermineerd
> waren

Begrijp je ueberhaupt wat het verschil tussen ATM's CBR/UBR en IP QoS is? Ik
vertel je dat een Lotus Exige met de motor in het midden en achterwielaandrijving
qua wegligging superieus is, en jij bent opeens bezig je te verdedigen met
het argument dat Lada's tegenwoordig ook niet meer roesten en lang niet zo
vaak stuk gaan als vroeger. Ik heb het idee dat we een beetje langs elkaar
heen praten.

>> Blijkbaar heeft iemand zitten suffen. Multicast op ATM is niet
>> noemenswaardig anders dan op IP, en bied je zelfs meer mogelijkheiden dan op
>> IP. Zoals aparte PVC's voor telefonie, data en multicast, zodat je telefoon
>> ongehapert doorgaat, ondanks een streamende collega.

> Allemaal leuk en aardig, maar het provisionen van ATM crossconnects vanaf
> een ATM switch naar een DSLAM is een administratieve hel, zeker als je
> je DSLAM's gaat subtenden. En dat voor vele honderduizenden eindgebruikers.
> Een foutieve crossconnect op een ATM switch en je bent je hele dag bezig met
> het nalopen van alle crossconnects...

En nou doe je het weer. De claim was 'geen multicast op ATM' en ik laat zien
hoe. Ga jij uitleggen dat netwerkmanagement met vi en tftp een nachtmerrie
is. Daar hadden we het niet over, Ashwin.

> Dat is nou het leuke van ethernet, simpelweg wat vlan-netjes trekken, vpn's
> op een IP DSLAM aanmaken en het werkt.

Yeah. Nu nog eens, maar dan met 300.000 IP's, 1300 vlan's, QoS, trunks,
bundels, aggregratie, routing, misschien wat MPLS hier en daar, een
gescheiden topologie voor VoIP, en het verschil tussen ATM en IP is te
verwaarlozen. Het is te complex voor mensen, dus doe je het geautomatiseert,
en dan maakt het opeens geen reet meer uit. Blijft alleen over dat ATM wel
plesiosynchroon dataverkeer kan garanderen, en IP niet. Iets wat je graag
wilt in een voice-capabel netwerk. Weet je hoe lullig het is om een collega
een verdieping hoger te bellen en met 1.1 seconde latency te zitten, enkel
omdat iemand op kantoor Windows-Update doet en een ander de keynote-speech
van Jobs kijkt?

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

On 11 Jan 2005 19:17:36 GMT, Hans Spaans <me@usenet2005.hansspaans.nl>
wrote:

>>>Welk onderdeel van deze header behoeft uitleg ;-)
>>>
>>>X-Include: <humor.h>,<troll.h>,<sarcasme.h>
>>
>> Het onderdeel dat ik niet zie in mijn client zonder h in te drukken. ;-)
>
>Gebruik dan ook een echte client ;-)

Nog altijd beter dan die client die bij iedere versiewijziging de
(internet) headers onder een ander menu verstopt.

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

On Tue, 11 Jan 2005 22:35:28 +0000 (UTC), Ruben van der Leij
<ruben-news@nutz.nl> wrote:

>> Het is niet het soort auto waarvan er in Enschede en omgeving 50% van de
>> Nederlandse hoeveelheid rondrijden.
>
>http://its.blacklisted.nl/~ruben/daf-126-2.jpg ? Dan weet ik de andere
>namelijk te vinden. :P

Volgens mij heeft de eigenaar van die DAF heeft er (geverifieerd) twee
van http://www.hummer.com/. Eentje geel (H2) en eentje zwart (H1
pickup). De derde die hier is gesignaleerd is nog niet aan diezelfde
persoon gekoppeld.

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

In article <slrncubikl.7at.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>Blijft alleen over dat ATM wel
>plesiosynchroon dataverkeer kan garanderen, en IP niet.

Op links met 12 Mbit/s of hoger zie ik in theorie het probleem niet.
Maar ik heb geen idee hoe goed de QoS implementaties van routers en
ethernet switches zijn.

Het grote probleem van frame switching t.o.v. van cell switching is dat
een frame uit de best effort class (relatief veel) vertraging op kan leveren
voor QoS verkeer. (In het algemeen kan je stellen dat ieder frame met een
hoge prioriteit per hop vertraagd kan worden door precies 1 frame met
een lagere prioriteit).

Bij tenminste 12 Mbit/s en een maximale frame grootte van 1518 bytes
kan je uit op een maximale vertraging van opgeveer 1 ms per hop.

>wilt in een voice-capabel netwerk. Weet je hoe lullig het is om een collega
>een verdieping hoger te bellen en met 1.1 seconde latency te zitten, enkel
>omdat iemand op kantoor Windows-Update doet en een ander de keynote-speech
>van Jobs kijkt?

Dan heb je dus of geen QoS, je links zijn veel te traag.


--
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-13, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:

>>Blijft alleen over dat ATM wel plesiosynchroon dataverkeer kan garanderen,
>>en IP niet.

> Bij tenminste 12 Mbit/s en een maximale frame grootte van 1518 bytes
> kan je uit op een maximale vertraging van opgeveer 1 ms per hop.

'Minder dan 1ms per hop' is natuurlijk geen garantie.

Misschien dat dit iets duidelijk maakt: ook de telco's die ronkende
persberichten over VoIP uitgeven blijken in de praktijk vaak VoATM te doen.
Omdat er IP-over-ATM over hetzelfde netwerk lijkt te gaan raakt Marketing in
verwarring. Neem de directe aanleiding voor dit takje, Versatel. Die zijn
begonnen met het bouwen van een SDH-netwerk. Zeg maar ATM, maar dan een
maatje groter, met ringen door Nederland op STM64 en STM256. Het idee
destijds was om bandbreedte naar behoefte te verdelen tussen 'klassiek' AAL2
en AAL5 met daarover een MPLS netwerk. Later is er een tweede netwerk naast
gelegd wat enkel MPLS/IP doet, en AAL5 is uit het voice SDH-netwerk
verdwenen. Gemengt verkeer naar een klant wordt in de centrale uit elkaar
geplukt en gaat gescheiden over de twee ringen.

Van de centrale naar de klant vind je twee scenario's. Ofwel twee aparte
links, of een PVC voor voice met een voldoende ruime CBR en de rest UBR
voor data over een DSL of iets snellers.

>> Weet je hoe lullig het is om een collega een verdieping hoger te bellen
>> en met 1.1 seconde latency te zitten, enkel omdat iemand op kantoor
>> Windows-Update doet en een ander de keynote-speech van Jobs kijkt?

> Dan heb je dus of geen QoS, je links zijn veel te traag.

We hebben het hier over links die meestal blijven steken op 2.3Mbit/s. Ik
heb dezelfde constructie thuis, maar dan over ADSL. Een 2-8/1-lijn, met
193Kbit/s CBR in een PVC voor voice, en de rest UBR in een andere PVC voor
data. M'n modem termineert de ene PVC als ISDN2, en bridged de ander naar
ethernet en m'n router. 'Mijn' provider doet ook z'n distributie geheel met
ATM, dus men splitst de andere kant pas op Telecity-1 in data en voice.
Omdat het hele pad voor voice CBR is kan dat zonder kwalijke gevolgen.

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

In article <slrncue3mp.kqo.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>On 2005-01-13, Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>>>Blijft alleen over dat ATM wel plesiosynchroon dataverkeer kan garanderen,
>>>en IP niet.
>
>> Bij tenminste 12 Mbit/s en een maximale frame grootte van 1518 bytes
>> kan je uit op een maximale vertraging van opgeveer 1 ms per hop.
>
>'Minder dan 1ms per hop' is natuurlijk geen garantie.

Hoezo? Als het maximaal aantal hops bekend is, dan heb je dus een garantie.

>>> Weet je hoe lullig het is om een collega een verdieping hoger te bellen
>>> en met 1.1 seconde latency te zitten, enkel omdat iemand op kantoor
>>> Windows-Update doet en een ander de keynote-speech van Jobs kijkt?
>
>> Dan heb je dus of geen QoS, je links zijn veel te traag.
>
>We hebben het hier over links die meestal blijven steken op 2.3Mbit/s.

1.1 seconde op 2.3Mbit/s is 2530000 bits times, of 316 kbyte. Dan heb je
dus of 208 hops achter elkaar of je hebt ergens geen QoS.


--
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 Fri, 14 Jan 2005 11:43:04 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:

>>>>Blijft alleen over dat ATM wel plesiosynchroon dataverkeer kan garanderen,
>>>>en IP niet.
>>
>>> Bij tenminste 12 Mbit/s en een maximale frame grootte van 1518 bytes
>>> kan je uit op een maximale vertraging van opgeveer 1 ms per hop.
>>
>>'Minder dan 1ms per hop' is natuurlijk geen garantie.
>
>Hoezo? Als het maximaal aantal hops bekend is, dan heb je dus een garantie.

Je weet het aantal hops niet. Je weet dat er maximaal zo'n 250 hops zijn
die zich als router gedragen. Maar je weet niet hoeveel hops er zijn die
op laag 2 functioneren. 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.

Via ADSL kan ik thuis zonder problemen aan VoIP doen, maar onze
kabelaansluiting heeft te veel variatie om daar een bruikbare verbinding
over te draaien.

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

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

>>We hebben het hier over links die meestal blijven steken op 2.3Mbit/s.

> 1.1 seconde op 2.3Mbit/s is 2530000 bits times, of 316 kbyte. Dan heb je
> dus of 208 hops achter elkaar of je hebt ergens geen QoS.

Zeldzaam. Echt. Zo zie je ze niet vaak.

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.

In article <n8ffu0hk8trg5tn0jv2i6rje37hs9i8s59@4ax.com>,
Peter Peters <peter.peters@utwente.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.
Probleem is natuurlijk dat in de praktijk het netwerk niet meewerkt, waardoor
je geen QoS parameters krijgt.

>Via ADSL kan ik thuis zonder problemen aan VoIP doen, maar onze
>kabelaansluiting heeft te veel variatie om daar een bruikbare verbinding
>over te draaien.

Maar dat wordt (naar ik aanneem) weer veroorzaakt door een gebrek aan QoS
ondersteuning. De totale downstream van de kabel is behoorlijk hoog, dus
daar zou een QoS stream juist weinig variatie moeten zien. Upstream wordt
geloof ik gepolld (of gebruiken ze tegenwoordig collission detection?).
Dat lijkt me wel een probleem.


--
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 1105740674 41907 213.239.176.42 (14 Jan 2005 22:11:14 GMT)
X-Complaints-To: usenet@nl-news.euro.net
NNTP-Posting-Date: Fri, 14 Jan 2005 22:11:14 +0000 (UTC)
Cancel-Lock: sha1:doqRCFAn92vzwpnvdRGTMp6vWx4= sha1:M9OzavFPzPryLAg2N60vLBs/fB8=
User-Agent: slrn/0.9.8.0 (Linux)
Xref: nl-news.euro.net nl.internet.providers:151837

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?

> Probleem is natuurlijk dat in de praktijk het netwerk niet meewerkt, waardoor
> je geen QoS parameters krijgt.

http://www.networkmagazine.com/share...cleID=16600121

"DSL and QoS. Two things that don't usually go together."

--
Ruben

Tijd dat Remkes opstapt. Genoeg is genoeg.