[e2e] Re: crippled Internet

[Vernon Schryver]

> From: "Eric A. Hall" <ehall at ehsco.com>

> ...
> > why not ship a PCI, USB, or Firewire device including CODECs, Ethernet,
> > UART, CPU, DSP, and whatever else you want?  If necessary, make the PC
> > no more than a GUI.

> ...
> It depends on what market you're talking about (and this thread has
> covered most but not all of them). For branch offices with less than 30
> users it is absolutely a cost effective solution if you are already
> ...

That has nothing to do with desktip VoIP.  Devices (including those
consisting mostly of software) to replace or connect to a PBX, even
a PBX serving only two desks, are unrelated to what David Reed and
most others here have been talking about.

>                                   ...    This especially includes
> telecommuters with fixed data access (nailed up ISDN or DSL).

DSL maybe, but not ISDN.  A single 128 kbit/sec 2B+D BRI (or IDSL)
link does not have enough bandwidth to share between a computer and
a phone, compared the better solution of getting separate pairs for
voice and data.  (I say that as a long term 100% telecommuter with
ISDN who must and has fought my RBOC for 10's of months for additional
pairs.) 128 kbit/sec is "low speed" today for purely computer use,
and so can't spare a 30 kbit/sec for voice even where David Reed is
wrong about lame drivers and PPP.


> ...
> > Desktop VoIP is dead for the foresseable future not because it doesn't
> > work and not because it is too expensive, but because it is too much
> > hassle compared to the almost free alternative of $0.05/minute or less
> > for any-U.S.-phone-to-any-U.S.-phone.
>
> This ignores the unfulfilled promise of advanced integration. Packetized
> voice allows for much more than flash-hook features can ever provide.
> Packetizing voice traffic means being able to do things like link a
> customer record with a call and then transfer them *as a pair*. While
> current CTI solutions allow for looking up callers data based on CID, they
> don't let you forward the database query along with the call. There are a
> million more examples, more than we can imagine, and this is the true
> promise for VoIP.

That has nothing to do with desktop VoIP.

"Advanced integration" outside the very specialized telemarketer or help
desk world involves the craziness evident in the do-all tools in zillions
of discount bins.  No one who really needs a screwdriver wants one of
those fat-handled screw drivers with 6 bits that is also a socket wrench
and a hammer.  Anyone who uses hand tools more than a few minutes/week
gets a set of open-end and box-end wrenchs, 1/4", 3/8", 1/2" and maybe
3/4" normal and deep sockets as well as half dozen screw drivers and as
many more screw, torx, and hex driver bits, plus half a dozen hammers.
Similarly, no one who uses a telephone as much as the typical N.American
or European consumer will tolerate a telephone tied to a desktop computer.
The best hope for that sort of "advanced integration" is in the PDA's+Cell
phones, which still get lots of gee-whiz talk in the trade rags and
terrible reviews by people who care about using the things.

That might change in the distant future when every house has a PBX
that also runs the household appliances, environmental, and security
systems and has voice-actived GUI's in every room and a virtual reality
interface for serious computing in the den or when your PDA has a
heads-up display.  But neither has anything to do with a 2001 vintage
desktop running Windows XP, no matter how "converged" or "integrated."


> ...
> Regarding TOS-based routing, the oddball observation from my tests showed
> that nailed-up ISDN was better for VoIP transit because the channels were
> committed bandwidth. If you could guarantee that voice calls went over B1
> and data went over B2, you would getter perfomance from VoIP and the TCP
> applications than if you ran them both over a shared 384k DSL circuit.

That is not and cannot be the case with reasonable software that
actually has TOS support.  64k kbps for voice and 64 kbps for data
(or 128 and 128 if you have two BRI's) is less and works worse than
384 kbps for voice and data.  In other words, that is at best a
restatement of David Reed's statement that Windows is not up to
the task, and the worst parts don't come from Microsoft but are
the drivers from the network and sound hardware vendors.


>                                                                     The
> use of TOS markings made a lot of sense for doing the custom bonding and
> for routing over intermediary networks, although nobody supported TOS
> routing with ISDN routers at the time to my knowledge, 

The big problem with IP TOS for ISDN is not in the consumer boxes,
since I think I can name two big vendors that support it.  E.g. what
about the Cisco SOHO boxes with the real IOS like the 800 series?
The big problem for IP TOS for ISDN is the same as for VJ header and
CCP data compression.  The access router vendors are...well...never mind.


>                                                        and OSPF was
> dropping it, so we ended up forcing the tests with static routes and a lot
> of praying.

This is the second time recently read someone claiming OSPF is related
to IP TOS and diff-serv.  Do people really think that diff-serv and
IP-TOS are impossible in the Internet, since it uses BGP instead of
OSPF?  Are people confusing policy routing with diff-serv and IP TOS?

Once again with feeling, IP TOS has nothing to do with routing!

Static routes or OSPF have nothing to do with how you manage queues. 
IP TOS or diff-serv is implemented in the bowels of the network drivers,
not up in the user space processes that know about OSPF, BGP4, RIP, and
static routes or over in the route-lookup code.  OSPF is about boxes
agreeing what to tell their forwarding engines how to pick output
interfaces.  Forwarding is about picking output interfaces.  IP TOS and
diff-serv happens long after the forwarding machinery has irrevocably
committed to a packet is an output interface.  IP TOS and diff-serve
don't care whether static routes or OSPF picked an interface.


Vernon Schryver    vjs at rhyolite.com