-

Open Economies - RE: [OpenEconomies] A "must read" forward: Trans-Pacific Tour, part two -- SMART Lett er #81

Mailing List Home

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [OpenEconomies] A "must read" forward: Trans-Pacific Tour, part two -- SMART Lett er #81

  • To: <openeconomies(at)cyber.law.harvard.edu>
  • Subject: RE: [OpenEconomies] A "must read" forward: Trans-Pacific Tour, part two -- SMART Lett er #81
  • From: "Elliot Noss" <enoss(at)tucows.com>
  • Date: Thu, 2 Jan 2003 17:49:04 -0500
  • Importance: Normal
  • In-reply-to: <oq1y3vjkz2.fsf@balthasar.nat>
This post, IMHO, just misses the point with respect to whether "a single
service should be provided in layers by more than one company."

I will try and be succinct and not engage in a long, technical discussion
but try and keep this at a business level. In North America the providers of
monopoly infrastructure have done everything in their power to create
artificial scarcity and to disincent use of the network. This can be seen
even in the way they provision dsl and cable with PPPoE and forced caches
and in the way they dissuade running servers of any sort (I am not
advocating the "home porn server" here but the running of services that
require some state). They try and force intelligence onto even the packet
network and they would seem to prefer that the network is used as little as
possible.

They focus on fighting the (lawful) access to the networks that
third-parties are legally entitled to rather than on customer service and
new services. Isn't it amazing to think about the fact that NOT ONE RBOC has
a respectable web hosting business. Dwell on that for a second.

As for the i-mode/Riccochet example, the reason for the success of i-mode is
that it was launched with an eye towards applications and incenting
third-party development of same. Riccochet was/is a different breed and
calibre of service that failed on its own merits. If you want to see "stupid
networks" at work in the wireless world just continue to watch 802.11 as it
both subsumes much of the need for wireless (2.5 or 3G) Internet access and
obviates the need for dsl/cable broadband in much of the US. IMHO, by the
end of 2004, third-parties providing broadband over 802.11 will be the
leading providers of broadband in the US on a cumulative basis. The number
one reason for this will be telco/cableco intransigence NOT technical
superiority. They will do their longhaul with the Level 3's of the world.
The only thing that can stop this steamroller is telco/cableco lobbying with
the FCC leading to limitations on free spectrum, which is, unfortunately, a
very real possibility.

The Internet has proven the business sense of the stupid network argument
time and time again as every single market for Internet services is
incredibly competitive with amazingly low concentration ratios. The less
infrastructure, the lower the concentration ratio. For a view of the way the
future should look see http://www.stokab.se/templates/Page.asp?id=2032 .

Lastly, I assume the writer has never used a SIP phone.

Regards

Elliot Noss
Tucows inc.
416-538-5494

> -----Original Message-----
> From: Miles Nordin [mailto:carton@Ivy.NET]
> Sent: Thursday, January 02, 2003 4:33 PM
> To: openeconomies@eon.law.harvard.edu
> Subject: Re: [OpenEconomies] A "must read" forward: Trans-Pacific Tour,
> part two -- SMART Lett er #81
>
>
> I am somewhat suspicious of this David Isenberg
> character---subjectively from the way he seems to be milking getting
> let go by Bell Labs into a touring speaking career, but also partly
> from the content of his message.
>
> I think the ``stupid networks'' thing is pretty well-understood by
> everyone who has had technical exposure to the Internet, including
> telco monopolies.  The standard technical objection is about QoS.  The
> telco guys I've heard talk about it do seem to have some
> mechanical-switching brain-damage, using words like ``fundamentally
> non-deterministic,'' and I don't much like them, but the QoS issue is
> relevant.
>
> Voice requires QoS because eacho VoIP packet must be delivered soon
> after it's sent, with small variance in how long it takes to be
> delivered.  Otherwise, the speaker's voice will drop out, or the delay
> between when you tell a joke and the other guy laughs will be too
> long.
>
> QoS is a challenge especially over the last mile on link types that
> aren't point-to-point, such as cable Interweb connections with
> 30Mbit/s shared channels, or wireless devices that have to share an
> actual over-the-air channel.
>
> The trivial hack to get QoS on these broadcast networks is to use
> short reservation packets to chaotically allocate timeslots for long
> data packets.  802.11b uses this now to avoid data packet
> collisions---you want to have only one AP per nonoverlapping channel
> because the AP grants timeslot reservations to its associated cards,
> preventing cards from colliding with each other's transmissions.  The
> granter of the reservations could also implement QoS scheduling by
> granting timeslots to VoIP cards such that they get frequent and
> predictable access to the band.
>
> Unfortunately, this trick doesn't actually work for VoIP because the
> data packets are too short.  A long 1.5kB data packet with the GSM
> codec would be more than one full second of voice, so the delay of
> waiting for this packet to fill before transmitting it is annoying to
> the listener.  VoIP must, and does, use small packets, less than 100
> data bytes.
>
> Besides the lack of QoS scheduling on broadcast networks, there is
> another issue with broadcast links and VoIP.  Because VoIP packets are
> small, they're mostly headers.  Obviously it varies depending on the
> upper-layer protocols like IPv4 vs. IPv6, 802.11 vs. Ethernet, but the
> headers and the data of a VoIP packet are probably about the same
> size.  There are tricks around this.  Over a slow or heavliy-used
> point-to-point link, one can use stateful header compression to notice
> virtual circuits without actually nailing them down telco-style, thus
> reducing 20 - 60 byte headers to more like 1 - 5 bytes, although
> depending on what else traverses the link this might be an unnecessary
> exercise.  Over a broadcast link, header compression is impossible,
> but sometimes that's okay because with a fast link like a Fast
> Ethernet LAN or a cable interweb channel, one might reasonably shrug
> and accept the 100% overhead.
>
> The ATM approach to addressing overhead, based on my vague
> understanding and some speculation, is a mix between stateful header
> compression and maybe also using timeslots to imply addressing.  And
> the philosophy if not the ATM protocol itself is rigid and primitive
> enough to extend to wireless cel networks.
>
> However, over a wireless network, the current ``non-deterministic''
> packet-switching tricks I've described above break down.
> Consequently, VoIP over a wireless network is colossally stupid,
> because it makes very poor use of the band---poor use becasue there is
> no obvious trick to reduce collision overhead with short packets, and
> poor use again because most of what you transmit will be packet
> headers.  There's no easy way around it because per-link-stateful
> header compression doesn't work on broadcast links.  When most of the
> bits are voice bits, as they are for cellular, wasting half the
> bandwidth is very expensive in crowded cellular spectrum so we can't
> just shrug off the overhead.  It's more efficient to (1) use ATM-style
> nailed-route constant-bitrate PVCs as existing cel networks do,
> solving both the collision problem and the header-compression problem,
> or (2) expose a Nextel-style push-to-talk interface to the user, where
> a four-second delay (and thus a larger packet) is tolerable.
>
> now, grizzled telco veterans calling a cellular network
> ``fundamentally deterministic'' is ridiculous---we all know that to
> perform acceptably to their users, cel networks must tolerate packet
> loss far exceeding the typical ``non-deterministic'' wired networks
> that our kind of people build.  But you must grant that cel networks
> solve (1) the broadcast-QoS problem, (2) the Alohanet collision
> problem, and (3) the small-packet header-tax problem, in ways that no
> existing VoIP-over-wireless architecture does.
>
> In the end, I think his ``stupid network'' argument is, kind of,
> simply wrong.  depending on how you look at it.  By the time
> Internet-ancestry networks can support, say, a cel full of gabby
> wireless voice users, they will probably be even more complicated than
> existing telco networks.  They may be more flexible than telco
> networks, but they will not be ``stupid'' by any metric compared to
> ATM and SS7.
>
>
> The other piece of his ranting seems to be that a single service
> should be provided in layers by more than one company.  From a
> business perspective, I think this part of the good professor's
> mystical hand-waving is equally suspect.  I like the idea very much,
> but the only evidence I see suggests that it simply doesn't work.  To
> me, the message of the wireless revolution in Korea and Japan, and of
> the astonishing failure and low subscribership of the amazingly
> brilliant Ricochet network in the US, is that _the keitai matters_.
> Matters most, even.
>
> The US had CDPD, DataTAC, Mobitex, and Ricochet long before the 1999
> release of DoCoMo's i-mode in Japan.  People think Japan had wireless
> Internet first, yet the US had no fewer than four ``stupid networks''
> that could get you wireless IP access.  Where were all those people
> who David supposes would emerge through market magic with wireless
> laptops plugged into the Innurnet, downloading smart applications to
> use over the existing stupid IP networks?
>
> i-mode, OTOH, was released as an integrated network with all the
> layers under NTT DoCoMo's control, and it continues to do great, with
> wanna-be i-modes in Taiwan, France, Germany, and the Netherlands; AT&T
> and Orange signed up to do i-modes soon, and similar-looking
> competitors within Japan (KDDI EZweb and Vodafone J-Sky) and outside
> (Korea).  Now US carriers, with underlying networks that perform much
> more poorly than Ricochet, are making their own telco-controlled
> i-mode competitors---with ``Get It Now,'' ``PCS vision,'' the GPRS
> Blackberry, danger.com's ``hiptop.''
>
> Successful wireless networks are all about good integration and cool
> handsets/terminals.  Ricochet had no handset/terminal at all---it was
> one of these PC Card form-factor services.  Everyone's first question
> about these little gizmos is always, ``how fast is it?''
>
> Who cares?  They do not ask, ``is it cheap?  are there holes in the
> coverage?  does the battery last all day?  can I stay logged in all
> day, or are there frequent inexplicable service interruptions that
> `kick you off?'  do I get a static non-NAT IP address so I can use
> 'push' services like AIM or ringing-email, or is it strictly proxied
> 'pull' Interweb NAT nonsense?  does it mysteriously space out from
> time to time, dropping all packets for about 60-second intervals like
> CDPD?  how well does it work with moving terminals in trains/cars?
> given proper investment, is the technology capable of continuing to
> perform like this as more people subscribe?'' all of which are more
> important than speed.
>
> Maybe this complexity explains why success requires a single
> system-wide integrator.  Or maybe the investment cost of building a
> terminal explains it.  Or maybe people just don't like stuff that
> snaps and plugs together with lots of fragile snapon connections,
> tangled wires, and software misconfiguration.  But, for whatever
> reason, ``stupid networks'' have been a remarkably consistent loser in
> wireless data.  You get your packets, your terminal, your
> applications, and some kind of server back-end or proxy, all from the
> telco monopoly.
>
>
> btw someone told me that Vonage sells VoIP phone service with US area
> codes, using your existing Internet connection.  so it is not just a
> tied service offered by Yahoo! BB.  This is, however, very different,
> because when Yahoo! BB offers it over their own DSL circuits they have
> a point-to-point link between your house and their infrastructure over
> which they can do QoS, while Vonage basically has to cross their
> fingers.  Yet another case of end-to-end stupid-network technology
> available right now, and no one gives a shit.
>
> --
> In science one tries to tell people, in such a way as to be understood
> by everyone, something that no one ever knew before.  But in poetry,
> it's the exact opposite.
> 		-- Paul A. M. Dirac, quoted by H. Eves
>
> _______________________________________________
> Openeconomies mailing list
> Openeconomies@eon.law.harvard.edu
> http://cyber.law.harvard.edu/lists/info/openeconomies
 
 
-