[nycbug-talk] Cogent and Sprint - a signal of things getting Oldschool?

[Miles Nordin]

>>>>> "ap" == Alex Pilosov <alex at pilosoft.com> writes:
>>>>> "il" == Isaac Levy <ike at lesmuug.org> writes:

    ap> Pay more money for a reliable service.

for me $340/mo T1 loop was less reliable than $50/mo DSL loop, and
*vastly* less reliable than one Verizon DSL + one Covad DSL.  If you
want reliability i think you need to get two of something because the
business-class-enterprise claims seem to be a wooden cart full of
baloney.

The extra cost seems more for service that's flexible:

 * bit-for-bit TDM service handed off as T1 on both ends---L2 exposed
   to the customer---that works well if you want to set up your own
   Cisco QoS, rather than handed off as L3 so QoS is hard and works
   shittily and inefficiently.  also on T1 L2 Cisco can do weird
   things like split big packets and send small ones in the middle so
   small ones experience less jitter.  you cannot do this with the L3
   over ATM cheapo DSL stack.

 * symmetric service, if you are doing ``interesting'' things that
   require upstream rather than interweb downloading advertisements
   like grandma

The scheme is, design one package to capture almost all the customers,
and compete for the pool vigorously.  Make sure the package doesn't
accomodate everyone so you don't ``cannibalize your higher-end
products.''  soak whoever's left for whatever the market will bear.

    il> If we have a world where 30mb/s down [$75/mo] [...]  why is
    il> bandwidth at the datacenter still so expensive?!

dunno, just gave one idea, gave some better ideas earlier, but at
least high datacenter prices have nothing to do with the ``BINGO''
alohanet L1 stuff I spoke about which doesn't even apply to the
ADSL/SDSL price difference much less prices for people without a last
mile.

    ap> If your carrier (say, time warner) bundles
    ap> access to Springer with your interwebs access, and (say,
    ap> cablevision) bundless access to Geraldo, what's wrong with
    ap> that?

because we'll complain about something else later, and you'll say ``If
you don't like Springer, then just watch Geraldo instead.  He has
competition.''  But we can't watch Geraldo without getting a new phone
number.  That's what it means, tying products together.  using one
monopoly to grab another.

but really I'm dreaming of busting television open, so that cable
companies and TV stations are no longer gatekeepers of what gets a
channel number on the dial and what doesn't.

The cable companies are terrified of Youtube, and anything else that
might replace television.  I expect their ultimate nightmare is being
forced to give Internet players equal access to their customers'
televisions, with the same QoS reservations and multicast efficiency
they use to deliver ``bundled'' private TV to their DRMboxes.

When you talk about ``someone will have to pay for it,'' customers,
taxpayers, someone, you're talking pay for implementation cost.  This
type of equal access is a threat to their business model, their
ability to vertically integrate, their ability to _grow_ the APRU they
can squeeze from their territory.  Compared to this threat I suspect
they could give a shit about the added technical cost of securing
QoS/mc interfaces for outsiders.  They don't want their vertical tower
sliced.  It's not about cost at all---it fucks their whole business
plan by opening television to competition.

Right now they're gatekeepers.  They keep TV off the Internet, and
they keep the Internet off your television.  They're the troll under
the bridge.  A fuck they could give about cost.  It's more like, ``the
LAST thing in which we'd dream of investing is something that gives
our customers more choices, and thus gives us more competition.''  Yet
multicast and QoS do just that.  

Optimistic about ``markets'' you might imagine, ``if multicast and QoS
are wanted, then the market will bring them about, because people will
pay for them, and if people will pay then ISP's will build.''  no
fucking way.  it will not happen, not cable companies!

Even when there's competition here, there is nothing like an open
market or a free choice.  There's a landscape, and they're
manipulating it.  We're entitled to some power to change the
landscape, too.

    il> if everybody is sending multicast, (let alone just the TV
    il> shows), that's a *lot* of data...

not sure where the confusion comes from.  Multicast is strictly less
data on each link that makes up the internet than it would take to
accomplish the same amount of TV watching with unicast ``streaming''.
You shuld probably just read about multicast.

The scalability downside to multicast is that it requires state on
each intermediate router for each multicast flow passing through it.
but there are a few tricks, and there are routers that are just Big.
It's possible to flood all multicast near the core if necessary.  Also
the MPLS-VPN thing (the standards Speakeasy uses to implement their
``private WAN'' service) has some way that each VPN customer inside
the MPLS can have as many flows as they like with a fixed amount of
state on the MPLS core routers.  I do not understand how this works
nor understand MPLS in general, but the point is the existing,
implemented standards are extremely ambitious and intend to handle
Internet-scale multicast.

note that there are non-TV-like applications of multicast.  There's a
reliable-delivery standard where the multicast source gets NAK's from
the destinations to unicast replacements for missed packets---one
could imagine many uses for this, like whiteboards, distributed
locking, Usenet-like file delivery.  This one has some complexity that
i don't understand to block ``NAK storms'' if there's an interruption
high in the spanning tree.  The other different kinds amount to
playing games with the destination group address, which are a scarce
resource and there is a lot of bickering about how to assign them, but
conceptually they could all be implemented with the same tools as the
IPTV case if you burned through more group destination addresses.
Among these there's many-to-many multicast where any subscriber to the
multicast group is also inclined to source traffic to the group, like
a multiplayer video game or a videoconference with split windows like
the intro to the brady bunch.  There's source-specific multicast where
the scope of the group destination address is the sender's IP, so you
cannot do many-to-many any longer but you can allocate the group
addresses yourself right on the source host without consulting anyone.
And there is some complicated minimally-implemented DHCP-ish protocol
for choosing group destination addresses.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20081102/8919895d/attachment.bin>