telecom planning to break VoIP over its network?
http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
So say bye bye to SIP, IAX, etc?
I wonder if i'll have to tunnel voip traffic.
Barry
----- Original Message -----
From: "Joe Abley"
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Would say it would cause problems for ipsec tunnels as well...
-----Original Message-----
From: Barry Murphy [mailto:barry(a)unix.co.nz]
Sent: Friday, 18 March 2005 1:34 p.m.
To: nznog; Joe Abley
Subject: Re: [nznog] telecom planning to break VoIP over its network?
So say bye bye to SIP, IAX, etc?
I wonder if i'll have to tunnel voip traffic.
Barry
----- Original Message -----
From: "Joe Abley"
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On Thu, 2005-03-17 at 19:25 -0500, Joe Abley wrote:
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
Maybe I misunderstand what Telecom is allegedly doing, but mucking about
with TCP won't do much. In order to specific target SIP (for example),
they'd have to intecept UDP/5060, parse off the SDP negotiations for
RTP, then muck about with the traffic on the ports mentioned in the SDP.
There's no specific port the audio will be on, tho some endpoints will
tend to use the same port.
Unless they're mucking with latency on _all_ packets, but that'd kill a
ton of other stuff off as well.
--
David Zanetti
On 17 Mar 2005, at 19:51, David Zanetti wrote:
Maybe I misunderstand what Telecom is allegedly doing, but mucking about with TCP won't do much.
I don't know anything more than what was in the article, but I presumed that the author had used "TCP" when in fact "IP" would have been more sensible. If "TCP" is just shorthand for "TCP/IP", then your analysis is probably over-literal.
Unless they're mucking with latency on _all_ packets, but that'd kill a ton of other stuff off as well.
A 500ms delay is easy to pick up on a telephone, and is about the right amount to make a conversation stilted and annoying. It's probably not obvious in many other (mainstream) protocols, though (although it'd hurt TCP performance, which people might pick up on). How about a differential queuing approach, whereby voice calls are normally fine, but suddenly sound like crap as soon as someone uses a web browser? You could always tunnel voice over something else, and if you were running a small, enterprise-scale service you'd probably get away with it. If you tried to do that for a commercial, residential SIP service, though, I have a feeling that your traffic would become classifiable fairly swiftly. Anyway, it seems odd that Telecom New Zealand was singled out for mention. Maybe that was just the name that came up when Cringley clicked the random-telco-name-generator, and it's not a reference to any leaked plan after all. Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 17 Mar 2005, Joe Abley wrote:
On 17 Mar 2005, at 19:51, David Zanetti wrote:
Maybe I misunderstand what Telecom is allegedly doing, but mucking about with TCP won't do much.
I don't know anything more than what was in the article, but I presumed that the author had used "TCP" when in fact "IP" would have been more sensible. If "TCP" is just shorthand for "TCP/IP", then your analysis is probably over-literal.
Probably, although I would still argue it's a lot of CPU, and they probably can't do that easily out at the edge to distribute it.
Unless they're mucking with latency on _all_ packets, but that'd kill a ton of other stuff off as well.
A 500ms delay is easy to pick up on a telephone, and is about the right amount to make a conversation stilted and annoying. It's probably not obvious in many other (mainstream) protocols, though (although it'd hurt TCP performance, which people might pick up on).
I think it'd seriously hurt lots of usage. 500ms on, say, the three way TCP handshake would make web-browsing really sluggish. Worse than dialup. 1.5 seconds to open a connection to request the umpteenth image of a page, you might as well not bother. (I know people go on about bandwidth and websites, but it's the latency people! Lots of images, high latency, you can have the bandwidth of gods and it'll still feel slow.. HTTP/1.1 pipelining notwithstanding..) And I'm certain there would be threads as long as my arm on nzgames.com about the total inablity to use DSL for games. :) There has been already, hasn't there?
How about a differential queuing approach, whereby voice calls are normally fine, but suddenly sound like crap as soon as someone uses a web browser?
Back to the old "stop using the 'net, I want to use the phone" :)
- --
David Zanetti | (__)
#include
On Sat, 2005-03-19 at 10:34 +1300, David Zanetti wrote:
I think it'd seriously hurt lots of usage. 500ms on, say, the three way TCP handshake would make web-browsing really sluggish. Worse than dialup. 1.5 seconds to open a connection to request the umpteenth image of a page, you might as well not bother.
Telecom could get around that problem easily. You just treat any packet with the SYN flag specially (i.e. exempt it from delay). In the bad old days (pre Southern Cross) when bandwidth was even more exorbitant than it is now we had Clear carry the bulk of our traffic via satellite (with high latency), but the hand shake went via terrestrial links along with other latency sensitive traffic such as Telnet. Russell
On 20 Mar 2005, at 22:39, Russell Fulton wrote:
In the bad old days (pre Southern Cross) when bandwidth was even more exorbitant than it is now we had Clear carry the bulk of our traffic via satellite (with high latency), but the hand shake went via terrestrial links along with other latency sensitive traffic such as Telnet.
and Doom!
Is it time that the govt. split up Telecom into little baby Telecom's. To get ADSL or UBSADSL you still *need* a Telecom land line dont you, so Telecom are still making a killing on the $35.whatever +gst they charge you per month to have that service. or if you live in Wellington or Christchurch $32.whatever +gst. If what has been posted on the list has happend, there is only one reason behind why -- and thats the voice department has had sway in how the IP department operates - which shows you that internal communication seems to be working with in Telecom (which is highly unusual for a telco espically TelstraClear) With all the advertising that goes on about the power and speed of broadband, is this false advertising? You see that kid playing that game, saying that his mother needs to use the phone (implying that Dial up can enable you to run real-time games) so ADSL must as well.. but then from what people have said here, UBS does not support realtime applications. I have cable, so have not been keeping up with the play on UBS, but is this the final version of it, last time I heard, they were having issues, and so implimented a *lesser* version until they could overcome some techinical problems with their network - has this been resolved now? If not, what does the legislation say on this???? On a side not, and not turning this political, (and it is election year) if a "geek" political party was formed to express the issues of geeks in parliement, given the number of "geeks" out there, do you think it would break the 5% threshold and get a seat in parliment on a party vote? On Mon, 21 Mar 2005, Joe Abley wrote:
On 20 Mar 2005, at 22:39, Russell Fulton wrote:
In the bad old days (pre Southern Cross) when bandwidth was even more exorbitant than it is now we had Clear carry the bulk of our traffic via satellite (with high latency), but the hand shake went via terrestrial links along with other latency sensitive traffic such as Telnet.
and Doom!
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Hmmm... But even geeks wont vote for a bunch of pimpled, bespectacled, hairy, cave trolls.... Or is that only describing the Developer and Unix SysAdmin community... [ducks] Perhaps if their campaign included free beer [to keep this on topic]... Later'ish Craig
-----Original Message----- From: Chris Hodgetts [mailto:chris(a)archnetnz.com] Sent: Tuesday, March 22, 2005 8:58 AM To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] telecom planning to break VoIP over its network?
[snip snip]
On a side not, and not turning this political, (and it is election year) if a "geek" political party was formed to express the issues of geeks in parliement, given the number of "geeks" out there, do you think it would break the 5% threshold and get a seat in parliment on a party vote?
Joe Abley wrote:
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
It's implied here that they identify the VOIP packets in order to bunch them. My VOIP tie line run across an encryted UDP VPN link so I can't see how they could affect just my VOIP traffic. Dave
Cisco NBAR picks up voip traffic.. (althought it wouldn't pick it up in daves case) im sure there are solutions from other venders that telecom would use to pick up the port the rtp's on etc.. It would just be really cpu intensive.. and cost more to do than it would benefit them.. -----Original Message----- From: Dave Green [mailto:dave.green(a)paradise.net.nz] Sent: Friday, 18 March 2005 1:55 p.m. Cc: nznog Subject: Re: [nznog] telecom planning to break VoIP over its network? Joe Abley wrote:
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
It's implied here that they identify the VOIP packets in order to bunch them. My VOIP tie line run across an encryted UDP VPN link so I can't see how they could affect just my VOIP traffic. Dave _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Telecom have denied multiple times in the press that they intend to do
this - particularly in reference to the use of Skype.
It should be noted that the Unbundled Bit Stream (UBS) offerings
specifically state that voice (or it might be all multimedia) is
excluded from working. In theory under the agreement they could do
this although they deny they will.
A bigger impact on VoIP is a couple of factors:
- lack of bandwidth. Most plans are 256 kb/s and upstream 128 kb/s.
Telecom had 192 kb/s on 1 mbit and 2 mbit plans but they are chopping
this back to 128 kb/s now. Don't get started on full speed plans as
they are far too expensive for most people. Basically if you are doing
anything else (e.g. P2P) it will kill your phone call unless you do
your own agressive traffic shaping. There is also lack of bandwidth at
peak times at present but one would hope that this is temporary
- packet dropping. Allegedly (it has been published in IDG but don't
want to guarantee it is correct) to get to a lower speed then ADSL
capable on UBS Telecom just throws the packets away semi-randomly.
This obviously has huge effect on TCP sessions and UDP streams as you
are going to get far less than what you have paid for as they will
retransmit the packet loss etc
Please note that these are my personal opinions and not those of any
organisation that I am associated with.
Regards,
Ian
On Thu, 17 Mar 2005 19:25:56 -0500, Joe Abley
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
In regards to Craig Spiers' comments, I doubt Telecom would see any amount
of processing power as justification not to render VoIP useless on their
networks. 20,000 Skype users must be hurting them.
I think you can be 99.9% confident that IDGs statements about UBS are
correct. Try using a VoIP application on a UBS line, especially during peak
times, and you'll see what I mean. In order to cap the speed to 256kbps
Telecom does just drop packets. I understand this is a limitation of the
current hardware at the exchanges, and that it will be replaced at some
point in the future by equipment which can queue packets instead (probably
when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP
either, it's a step forward from dropping them altogether. Queuing is
certainly more efficient for ordinary TCP and even streamed UDP traffic,
because data doesn't need to be resent from the source.
NZ needs some competition in the Telco market.
Regards,
Erin Salmon
Managing Director
Unleash Computers Ltd
Mobile: 021 877 913
Landline: 03 365 1273
www.unleash.co.nz
-----Original Message-----
From: Ian McDonald [mailto:imcdnzl(a)gmail.com]
Sent: 18 March 2005 2:27 p.m.
To: Joe Abley
Cc: nznog
Subject: Re: [nznog] telecom planning to break VoIP over its network?
Telecom have denied multiple times in the press that they intend to do
this - particularly in reference to the use of Skype.
It should be noted that the Unbundled Bit Stream (UBS) offerings
specifically state that voice (or it might be all multimedia) is
excluded from working. In theory under the agreement they could do
this although they deny they will.
A bigger impact on VoIP is a couple of factors:
- lack of bandwidth. Most plans are 256 kb/s and upstream 128 kb/s.
Telecom had 192 kb/s on 1 mbit and 2 mbit plans but they are chopping
this back to 128 kb/s now. Don't get started on full speed plans as
they are far too expensive for most people. Basically if you are doing
anything else (e.g. P2P) it will kill your phone call unless you do
your own agressive traffic shaping. There is also lack of bandwidth at
peak times at present but one would hope that this is temporary
- packet dropping. Allegedly (it has been published in IDG but don't
want to guarantee it is correct) to get to a lower speed then ADSL
capable on UBS Telecom just throws the packets away semi-randomly.
This obviously has huge effect on TCP sessions and UDP streams as you
are going to get far less than what you have paid for as they will
retransmit the packet loss etc
Please note that these are my personal opinions and not those of any
organisation that I am associated with.
Regards,
Ian
On Thu, 17 Mar 2005 19:25:56 -0500, Joe Abley
http://www.pbs.org/cringely/pulpit/pulpit20050317.html
"And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Erin Salmon - Unleash Computers Ltd wrote:
and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+).
No, Telecom said they'll start queueing with the 1 and 2Mbit/s UBS plans coming out soon. That was apparently one reason why it took so long to provide the faster plans. -- Juha
Erin Salmon - Unleash Computers Ltd wrote:
In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them.
I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source.
I have a special going on tinfoil hats at the moment. Stock is running out fast. -- Steve.
Steve Phillips wrote:
Erin Salmon - Unleash Computers Ltd wrote:
In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them.
I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source.
I have a special going on tinfoil hats at the moment. Stock is running out fast.
You're missing the big picture - how can we get VoIP to run across the Telecom brain-control rays? In-Head Skype could be an emergent technology.
On Fri, 18 Mar 2005, Steve Phillips wrote:
I have a special going on tinfoil hats at the moment. Stock is running out fast.
We'll take five: three XL, one L and one S. Plus a keg of beer, to keep this on-topic :P Seriously, though, does anyone doubt that Telecom might actually TRY something like this if it were at all possible? -- Matthew Poole "Don't use force. Get a bigger hammer."
Erin Salmon - Unleash Computers Ltd wrote:
While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source.
Thanks for the quick tcp/ip stack lesson, perhaps we should just block all ACK's seeing as we're going to queue everything and tcp loves queuing. -Rchrd (sorry, must've dropped some packets there)
NZ needs some competition in the Telco market.
We seem to have plenty of that. What we don't have is effective regulation/local loop unbundling (LLU). How many other countries in the OECD don't have LLU? Very few at all. Of course Telecom will object against LLU as it DOES hurt their bottom line and they are owned by shareholders. It really has to be a policy decision by the government. Once again, these are my personal views only.
At 14:27 18/03/2005, Ian McDonald wrote:
Allegedly (it has been published in IDG but don't want to guarantee it is correct) to get to a lower speed then ADSL capable on UBS Telecom just throws the packets away semi-randomly. This obviously has huge effect on TCP sessions and UDP streams as you are going to get far less than what you have paid for as they will retransmit the packet loss etc
There seems to be a bit of confusion by some people as to how traffic rate limiting and shaping works - to put it simply it is impossible to NOT drop packets, if you're trying to rate limit traffic, that is the whole basis of how rate limiting works. If packets are coming in too fast, you can only buffer them so much before you're forced to simply throw some away. TCP automatically recognises this loss and throttles the speed back until the loss no longer occurs, so the packet loss is only momentary usually just after a download starts, and a normal part of how things work. No way does it imply that you're going to have (for example) 30% packet loss on a continuous basis, so the "paying for retransmitions" argument is bogus. UDP on the other hand has no rate limiting mechanism, unless its handled at an application layer, but if you try to send faster than your link speed or the smallest bottleneck in a path with UDP you'll run into problems no matter what. Having a queue (buffer) too large only buys your more latency, and can actually be detrimental to overall performance, unless you start seperating different streams or types of traffic into different queues. (QoS stuff) Regards, Simon
What I was meaning (and I didn't state very clearly) was whether the
link is at full ADSL speed and packets thrown away at exchange that
exceed traffic rate or whether the link is running at speed purchased.
On Fri, 18 Mar 2005 16:28:10 +1300, Simon Byrnand
At 14:27 18/03/2005, Ian McDonald wrote:
Allegedly (it has been published in IDG but don't want to guarantee it is correct) to get to a lower speed then ADSL capable on UBS Telecom just throws the packets away semi-randomly. This obviously has huge effect on TCP sessions and UDP streams as you are going to get far less than what you have paid for as they will retransmit the packet loss etc
There seems to be a bit of confusion by some people as to how traffic rate limiting and shaping works - to put it simply it is impossible to NOT drop packets, if you're trying to rate limit traffic, that is the whole basis of how rate limiting works.
If packets are coming in too fast, you can only buffer them so much before you're forced to simply throw some away. TCP automatically recognises this loss and throttles the speed back until the loss no longer occurs, so the packet loss is only momentary usually just after a download starts, and a normal part of how things work.
No way does it imply that you're going to have (for example) 30% packet loss on a continuous basis, so the "paying for retransmitions" argument is bogus.
UDP on the other hand has no rate limiting mechanism, unless its handled at an application layer, but if you try to send faster than your link speed or the smallest bottleneck in a path with UDP you'll run into problems no matter what.
Having a queue (buffer) too large only buys your more latency, and can actually be detrimental to overall performance, unless you start seperating different streams or types of traffic into different queues. (QoS stuff)
Regards, Simon
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
participants (18)
-
Barry Murphy -
Chris Hodgetts -
Craig Humphrey -
Craig Spiers -
Dave Green -
David Zanetti -
David Zanetti -
Erin Salmon - Unleash Computers Ltd -
Ian McDonald -
Jeremy Brooking -
Joe Abley -
Juha Saarinen -
Justin Cook -
Matthew Poole -
Richard Patterson -
Russell Fulton -
Simon Byrnand -
Steve Phillips