Subject: [NEXTEL-1] Goldman- VoIP the enabler of real telecom competition

From: [email-masked]
Date: Fri, 01 Aug 2003 21:23:30 -0400

VoIP - the enabler of real telecom competition

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Todd Marshall <[email-masked]>
Date: Sat, 02 Aug 2003 12:11:55 -0500

Does anyone believe this statement for the linked article? It is so 
comical to see these VoIP proponents trashing their own hopeless past 
ideas in order to advance their equally hopeless future initiatives.

Todd Marshall

In traditional circuit switched telephony, a dedicated path, or channel, 
is opened
between the parties participating in the conversation. No other traffic 
can pass over
that channel while the conversation takes place. This dedicated channel 
remains open
until the parties terminate the call, thus freeing up the channel for 
use in another
conversation. In VoIP telephony, however, dedicated circuits are not 
used. Multiple
conversations are sent over the same channel, as separate streams of 
data packets. When
there is a lull in any particular conversation, other data packets can 
be carried over that
part of the network, thus making the network more efficient. In 
technical terms, VoIP
uses the network more efficiently because it combines, or multiplexes, 
multiple sets of
data over the same physical path.

[email-masked] wrote:

> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://rd.yahoo.com/M=259538.3625325.4914071.1261774/D=egroupweb/S=1707367802:HM/A=1695348/R=0/SIG=11u38u3s2/*http://hits.411web.com/cgi-bin/hit?page=1374-105951838331032> 
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.

---

From: "Todd Ellis" <[email-masked]>
Date: Sat, 2 Aug 2003 20:01:04 -0400

First, Todd, I have been reading your posts with a great deal of interest.
I did some work for a client investigating the methodology of TCP vs. UDP
for mobile applications a couple of years ago.  I also worked on a project
trying (successfully) to get a TCP application working through a UDP
conversion, and then porting the data through an MPT-1327-like data system
that transferred 100 bytes at a time.  Frustrating.

Anyways, the author apparently totally lost the concept that VoIP is not
TCP-based.  If it was, it would never happen on reasonable bandwidths!  It's
also an issue why data (like control channel data) can't generally be ported
on VoIP lines - latency is problematic.

Keep going!  ;)

Todd Ellis

Raleigh, NC 

-----Original Message-----
From: Todd Marshall [mailto:[email-masked]] 
Sent: Saturday, August 02, 2003 1:12 PM
To: [email-masked]
Subject: Re: [NEXTEL-1] Goldman- VoIP the enabler of real telecom
competition

Does anyone believe this statement for the linked article? It is so comical
to see these VoIP proponents trashing their own hopeless past ideas in order
to advance their equally hopeless future initiatives.

Todd Marshall

In traditional circuit switched telephony, a dedicated path, or channel, is
opened
between the parties participating in the conversation. No other traffic can
pass over
that channel while the conversation takes place. This dedicated channel
remains open
until the parties terminate the call, thus freeing up the channel for use in
another
conversation. In VoIP telephony, however, dedicated circuits are not used.
Multiple
conversations are sent over the same channel, as separate streams of data
packets. When
there is a lull in any particular conversation, other data packets can be
carried over that
part of the network, thus making the network more efficient. In technical
terms, VoIP
uses the network more efficiently because it combines, or multiplexes,
multiple sets of
data over the same physical path.

Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service. 

Yahoo! Groups Sponsor

ADVERTISEMENT
 
<http://rd.yahoo.com/M=259538.3625325.4914071.1261774/D=egroupweb/S=17073678
02:HM/A=1695348/R=0/SIG=11u38u3s2/*http:/hits.411web.com/cgi-bin/hit?page=13
74-105951838331032> click here

<http://us.adserver.yahoo.com/l?M=259538.3625325.4914071.1261774/D=egroupmai
l/S=:HM/A=1695348/rand=669888323> 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of
<http://docs.yahoo.com/info/terms/>  Service.

---

From: Todd Marshall <[email-masked]>
Date: Sun, 03 Aug 2003 21:07:23 -0500

Thanks Todd.

It's so obvious that when trying to drive voice, bandwidth is not the 
issue. Voice is relatively very very low bandwidth data. You have to get 
the horses out of the gate with great dispatch. And they can't stop for 
a drink along the way. You can have an OC12 pipe carrying a single voice 
channel  through nodes with services-providing 48x PowerPCs in the core, 
and VoIP won't get QoS if it has too many IP hops.

VoIP connections must be trunked to minimize hops. Those trunks must 
travel most of their way on a single link ... but this isn't a unit 
train of coal ... its a small package delivery service. Short of full 
mesh architectures, VoIP will easily exceed its hop tolerance without 
very serious, and wasteful, and manpower devouring traffic engineering.

Further, you can't have long trains on the same tracks with these little 
voice packets. So the MTUs get set very small and the long trains get 
broken up. The resulting IP packet tax now imposed on all traffic makes 
the 15% ATM cell tax (relative to IP's 30+% tax with these small 
packets) look like chump change. IPv4 has a 24 byte header. With a 
packet size of 100 bytes (probably too big to avoid anoying delays), the 
payload is 75 bytes and that's a 33% packet tax. The ATM header is 5 
bytes. The payload is 48 bytes yielding the 15% cell tax..  And it just 
gets much worse with IPv6.

I'm so perplexed as to why, while we have ATM specifically designed for 
this problem, and naturally acclimated for other cases like video 
conferencing and video streaming up to 640Mbps per connection, that 
we're going through this charade of making the IP pig's ear look like 
the ATM silk purse.

Why is this happening? IP has its place. Best effort web page browsing 
might be its place. FTP file downloads might be its place. Email 
transmission might be its place. But voice transmission will never be 
its place, and thus, unless you employ subtitling, video conferencing 
will never be IP's place either.

/Todd Marshall

P.S. Todd. I presume your tests also then revealed how UDP squashes TCP 
... thus the reasons for employing DiffServ and IntServ to mitigate that 
issue, which is what MPT-1327 appears to be another flavor of.

Todd Ellis wrote:

> First, Todd, I have been reading your posts with a great deal of 
> interest.  I did some work for a client investigating the methodology 
> of TCP vs. UDP for mobile applications a couple of years ago.  I also 
> worked on a project trying (successfully) to get a TCP application 
> working through a UDP conversion, and then porting the data through an 
> MPT-1327-like data system that transferred 100 bytes at a time.  
> Frustrating.
>
>  
>
> Anyways, the author apparently totally lost the concept that VoIP is 
> not TCP-based.  If it was, it would never happen on reasonable 
> bandwidths!  It's also an issue why data (like control channel data) 
> can't generally be ported on VoIP lines - latency is problematic.
>
>  
>
> Keep going!  ;)
>
>  
>
> Todd Ellis
>
> Raleigh, NC
>
>  
>
> In traditional circuit switched telephony, a dedicated path, or 
> channel, is opened
> between the parties participating in the conversation. No other 
> traffic can pass over
> that channel while the conversation takes place. This dedicated 
> channel remains open
> [email-masked] <mailto:[email-masked]> wrote:
>
> <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=1707367802:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=30504&media=atkins> 
>
>
>

---

From: "Rik Rasmussen" <[email-masked]>
Date: Mon, 4 Aug 2003 06:32:34 -0400

$$$$$$$$$ its always the $$$$$$$$$$

Users want to solve their problems using existing WAN connections instead of
having to budget large sums to get T1's installed for ATM.

Many of these users are local government where doing it cheap is the order
of the day.

Many UHF trunking operators would like to network sites if they could do it
with almost free internet service, but if they have to pay for ATM, the
business model goes to hell.

==========================================
Henrik "Rik" Rasmussen
Editor: Two Way Radio Directory:
The Two Way Radio Directory has links to hundreds of industry related web
pages.
The Directory Bookstore has a great selection of radio books at good
discounts.
Visit now at http://twowayradiodirectory.com/

  -----Original Message-----
  From: Todd Marshall [mailto:[email-masked]]
  Sent: Sunday, August 03, 2003 10:07 PM
  To: [email-masked]
  Subject: Re: [NEXTEL-1] Goldman- VoIP the enabler of real telecom
competition

  Thanks Todd.

  It's so obvious that when trying to drive voice, bandwidth is not the
issue. Voice is relatively very very low bandwidth data. You have to get the
horses out of the gate with great dispatch. And they can't stop for a drink
along the way. You can have an OC12 pipe carrying a single voice channel
through nodes with services-providing 48x PowerPCs in the core, and VoIP
won't get QoS if it has too many IP hops.

  VoIP connections must be trunked to minimize hops. Those trunks must
travel most of their way on a single link ... but this isn't a unit train of
coal ... its a small package delivery service. Short of full mesh
architectures, VoIP will easily exceed its hop tolerance without very
serious, and wasteful, and manpower devouring traffic engineering.

  Further, you can't have long trains on the same tracks with these little
voice packets. So the MTUs get set very small and the long trains get broken
up. The resulting IP packet tax now imposed on all traffic makes the 15% ATM
cell tax (relative to IP's 30+% tax with these small packets) look like
chump change. IPv4 has a 24 byte header. With a packet size of 100 bytes
(probably too big to avoid anoying delays), the payload is 75 bytes and
that's a 33% packet tax. The ATM header is 5 bytes. The payload is 48 bytes
yielding the 15% cell tax..  And it just gets much worse with IPv6.

  I'm so perplexed as to why, while we have ATM specifically designed for
this problem, and naturally acclimated for other cases like video
conferencing and video streaming up to 640Mbps per connection, that we're
going through this charade of making the IP pig's ear look like the ATM silk
purse.

  Why is this happening? IP has its place. Best effort web page browsing
might be its place. FTP file downloads might be its place. Email
transmission might be its place. But voice transmission will never be its
place, and thus, unless you employ subtitling, video conferencing will never
be IP's place either.

  /Todd Marshall

  Todd Ellis wrote:

---

From: "Todd Ellis" <[email-masked]>
Date: Mon, 4 Aug 2003 06:55:11 -0400

-----Original Message-----
From: Todd Marshall [mailto:[email-masked]] 
Sent: Sunday, August 03, 2003 10:07 PM
To: [email-masked]
Subject: Re: [NEXTEL-1] Goldman- VoIP the enabler of real telecom
competition

Thanks Todd. 

<snip> 

I'm so perplexed as to why, while we have ATM specifically designed for this
problem, and naturally acclimated for other cases like video conferencing
and video streaming up to 640Mbps per connection, that we're going through
this charade of making the IP pig's ear look like the ATM silk purse. 

<snip

/Todd Marshall

P.S. Todd. I presume your tests also then revealed how UDP squashes TCP ...
thus the reasons for employing DiffServ and IntServ to mitigate that issue,
which is what MPT-1327 appears to be another flavor of.

Good response!  

One point about ATM - not related to wireless communications.  One of the
technologies I strongly believe in is fiber to the home (FTTH) using ATM and
passive architecture.  Alcatel has by far the best solution to that product
niche of any in the marketplace.  Chopping out all of the wastefulness of
current distributed networks to this technology is critical.  Why entire
cities aren't clamoring to the technology can only be chalked up to cost and
ignorance; it is truly THE answer.  My hat's off to the Verizon folks who
are implementing such networks now.  That's forward thinking!

Back to mobile wireless data, UDP was the ONLY solution.  TCP slowed traffic
down from 1200 baud to 81 baud.  It was bad enough that the packets had to
go through a conversion process, but when the 30% overhead was added, the
thing crashed and burned.  The client got a UDP 800 baud system working just
fine (within pre-installation design time limits), and then Securicor went
out of business.  They are now working with a company called Sofia for
ultra-narrowband 220 MHz use, and are getting better throughput at 2400
baud.  BTW, the 5 KHz channel spacing leaves a practical limit of 4000 baud,
so chopping out overhead is crucial.  

Todd Ellis

Raleigh, NC

---

From: [email-masked]
Date: Mon, 04 Aug 2003 07:09:53 -0400

Reminds me of departments that are opting for Wi-Fi  instead of protected
spectrum.

Wi-Fi may be cheap but the jeopardy attached is costly.

I can see it now....................

Chief- "What do you mean Billy's Wi-Fi Playstation 2 across the street interfered
with the transmission Homicide Perp's mug shot?

Radio Tech- "Chief I told you Wi-Fi was for kids"

Chief- " The sales guy said we would save thousands!"

Radio Tech- "Should I order that T-1 now?

Chief- "Damn %@$*(?$ salesmen......yea order it.

Playstation 2 Wi-Fi
http://www.wified.net/content/wifiedhome/game.html

Rik Rasmussen wrote:

> $$$$$$$$$ its always the $$$$$$$$$$Users want to solve their problems using
> existing WAN connections instead of having to budget large sums to get T1's
> installed for ATM.
> Many of these users are local government where doing it cheap is the order of
> the day.Many UHF trunking operators would like to network sites if they could do
> it with almost free internet service, but if they have to pay for ATM, the
> business model goes to hell. ==========================================
> Henrik "Rik" Rasmussen

---

From: Todd Marshall <[email-masked]>
Date: Mon, 04 Aug 2003 06:37:44 -0500

I think we're getting into some semantic or context issues here. T1 is 
layer 1. ATM is layer 2. Any linkage viewed as a contraint has to be the 
result of  packaging. Any fear of cost can be traced to FUD.

The real issue is efficient management of the physical layer. Clever 
management at the data link layer delivers that. And ATM (especially the 
unbelievably clever and low cost UTOPIA-II chip sets) is the best 
alternative we have right now to deliver that clever management. It is 
much more difficult and expensive to try to manage layer 1 from layer 3 
and that's why we see the deficiencies and expense of IP approaches to 
these issues.

 ATM switches can work just fine with something as punny as DS3 or even 
DS0, or a collection of them, at layer 1. If each LAN had attached to it 
an ATM switch that had a physical link(s) (of any appropriate 
attributes) to say 3 or 4 other LANS which did the same, you then have a 
WAN in the form of a web. You use ATM SVCs to establish the connections 
(not links ... those are established by your layer 1 strategy) between 
the LANS "as demand calls for them in real time". You don't do a full 
mesh as Frame Relay wants to do. And you don't cast your data to the 
wind as IP wants to do.

The real issues are in the protocols. If you take a circuit emulation 
approach to get this connectivity you have taken a wasteful approach. On 
the other hand, if you use a protocol that cooperates with layer 3 on an 
as needed basis, and have formed a web rather than doing fan in, 
trunking, and fan out at layer 2 or full mesh at layer 1, then you have 
a better model.

If you take this approach to the limit (i.e. let anybody's web talk be 
part of anybody elses web at layer 2, as the internet routers do for IP 
at layer 3), you don't have "almost free", you have "free".

/Todd

Rik Rasmussen wrote:

> Users want to solve their problems using existing WAN connections 
> instead of having to budget large sums to get T1's installed for ATM.
>  
> Many of these users are local government where doing it cheap is the 
> order of the day.
>  
> Many UHF trunking operators would like to network sites if they could 
> do it with almost free internet service, but if they have to pay for 
> ATM, the business model goes to hell.
>  
> The Two Way Radio Directory has links to hundreds of industry related 
> web pages.
>     It's so obvious that when trying to drive voice, bandwidth is not
>     the issue. Voice is relatively very very low bandwidth data. You
>     have to get the horses out of the gate with great dispatch. And
>     they can't stop for a drink along the way. You can have an OC12
>     pipe carrying a single voice channel  through nodes with
>     services-providing 48x PowerPCs in the core, and VoIP won't get
>     QoS if it has too many IP hops.
>
>     VoIP connections must be trunked to minimize hops. Those trunks
>     must travel most of their way on a single link ... but this isn't
>     a unit train of coal ... its a small package delivery service.
>     Short of full mesh architectures, VoIP will easily exceed its hop
>     tolerance without very serious, and wasteful, and manpower
>     devouring traffic engineering.
>
>     Further, you can't have long trains on the same tracks with these
>     little voice packets. So the MTUs get set very small and the long
>     trains get broken up. The resulting IP packet tax now imposed on
>     all traffic makes the 15% ATM cell tax (relative to IP's 30+% tax
>     with these small packets) look like chump change. IPv4 has a 24
>     byte header. With a packet size of 100 bytes (probably too big to
>     avoid anoying delays), the payload is 75 bytes and that's a 33%
>     packet tax. The ATM header is 5 bytes. The payload is 48 bytes
>     I'm so perplexed as to why, while we have ATM specifically
>     designed for this problem, and naturally acclimated for other
>     cases like video conferencing and video streaming up to 640Mbps
>     per connection, that we're going through this charade of making
>     the IP pig's ear look like the ATM silk purse.
>
>     Why is this happening? IP has its place. Best effort web page
>     browsing might be its place. FTP file downloads might be its
>     place. Email transmission might be its place. But voice
>     transmission will never be its place, and thus, unless you employ
>     subtitling, video conferencing will never be IP's place either.
>
>     /Todd Marshall
>
>     P.S. Todd. I presume your tests also then revealed how UDP
>     squashes TCP ... thus the reasons for employing DiffServ and
>     IntServ to mitigate that issue, which is what MPT-1327 appears to
>     be another flavor of.
>
>     Todd Ellis wrote:
>
>>      
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT

---

From: Todd Marshall <[email-masked]>
Date: Mon, 04 Aug 2003 10:05:54 -0500

Good FUD.
/Todd

[email-masked] wrote:

> Reminds me of departments that are opting for Wi-Fi  instead of 
> protected spectrum.
>
> Wi-Fi may be cheap but jeopardy attached is costly.
>
> Chief- "What do you mean Billy's Wi-Fi Playstation 2 across the street 
> interfered with the transmission Homicide Perp's mug shot?
>
> Chief- "Damn %@$*(&#$ salesmen......yea order it.
>
> Playstation 2 Wi-Fi
>> $$$$$$$$$ its always the $$$$$$$$$$Users want to solve their problems 
>> using existing WAN connections instead of having to budget large sums 
>> to get T1's installed for ATM. 
>> order of the day.Many UHF trunking operators would like to network 
>> sites if they could do it with almost free internet service, but if 
>> they have to pay for ATM, the business model goes to hell.

---

From: Rick Parrish <[email-masked]>
Date: Mon, 04 Aug 2003 16:02:54 -0500

> ATM, the business model goes to hell.

ATM is getting cheaper.

Example: 1.5 megabit download/384k upload at $30 bucks a month.
Compare to full T1 which is 1.5 megabits in both directions for around 
$200 a month.

[ and if you know of something cheaper for full T1 rate, let me know - 
"ganging" four plain DSL lines together is a pain. ]

If you've got DSL - you've got ATM but you're at the mercy of the 
carrier's marketing policy.

-rick

---

From: Rick Parrish <[email-masked]>
Date: Mon, 04 Aug 2003 16:20:14 -0500

Counter FUD ...

[ warning: a severe, twisted sense of humor is required. ]

Reminds me of departments that are opting for licensed spectrum in the 
same band as Nextel.

Running your own two-way radio sysem may be cheaper (or not) than paying 
Nextel $70/month per handset but jeopardy attached is costly.

Chief- "What do you mean our radios sometimes go deaf? How is Homicide 
going to get a perp's mug shot? or NCIC, or [state]CIC?"

Radio Tech- "Sorry Chief, it most be that gosh darned Nextel tower down 
the street!"

Chief- "But I thought the FCC would protect us!"

Radio Tech- "Should I order that SEA 220 system, now?

Chief- "Damn %@$*(&#$ Nextel ... yea order it.

-rick

---

From: "Rik Rasmussen" <[email-masked]>
Date: Mon, 4 Aug 2003 20:43:01 -0400

You obviously don't live in a Verizon town.

T-1 = $500 bucks per month in town.

But, UHF trunking operators don't tend to buold their towers in town.

Henrik "Rik" Rasmussen
http://home.nc.rr.com/rikrasmussen/
Amateur Radio Extra Class WA4BAN

> From: Rick Parrish [mailto:[email-masked]]
> Sent: Monday, August 04, 2003 5:03 PM

---

From: Rick Parrish <[email-masked]>
Date: Mon, 04 Aug 2003 20:28:33 -0500

Rik Rasmussen wrote:

Which is obscene when you consider that Cogent Communications will sell
you a fractional OC3 for $1000 a month (see:
http://www.cogentco.com/).

Hmmm ... let me see now ... 1.5 megabits for $500 a month or 100
megabits for $1000. Gee, that's a tough decision.

Like I said, you're at the mercy of the carrier's marketing plan (or
you're buying from a reseller with too many middlemen).

Nah, they just lease dry pairs - which are much cheaper.

Henrik "Rik" Rasmussen

-rick

Yahoo! Groups Sponsor

ADVERTISEMENT

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.