Re: Observations of an Internet Middleman (Level3) (was: RIP

[Blake Hudson <blake () ispn net>]

Oh, I'm not proposing symmetrical connectivity at all. I'm just 
supporting the argument that in the context of this discussion I think 
it's silly for a residential ISP to purport themselves to be a neutral 
carrier of traffic and expect peering ratios to be symmetric when the 
overwhelming majority of what they're selling (and have been selling for 
over a decade) is asymmetric connectivity. Their traffic imbalance is, 
arguably, their own doing.

How residential ISPs recoup costs (or simply increase revenue/profit) is 
another question entirely. I think the most insightful comment in this 
discussion was made by Mr. Rick Astley (I assume a pseudonym), when he 
states that ISPs have several options to increase revenue A) Increase 
price of their product, B) Implement usage restrictions, or C) Charge 
someone else/Make someone else your customer. I think he successfully 
argues that option C may be the best. As we've seen, the wireless market 
in the US went for option B. We've yet to see where the wireline market 
will go.

Of course, the market would ideally keep ISPs' demands for 
revenue/profit in check and we'd all reach a satisfactory solution. One 
of the arguments, one I happen to support, in this thread is that there 
is not a free market for internet connectivity in many parts of the US. 
If there was, I believe Comcast would be focusing on how to provide a 
balance between the best product at the lowest cost and not on how they 
can monetize their paying customers in order to increase profits. I 
appreciate honesty; When a service provider advertises X Mbps Internet 
speeds, I expect they can deliver on their claims (to the whole 
Internet, and not just the portions of it they've decided). I understand 
congestion, overselling, etc. But choosing which portions of the 
internet work well and which don't is a lot more like censorship than 
service.

--Blake

Scott Helms wrote the following on 5/16/2014 12:39 PM:
> Blake,
>
> You're absolutely correct.  The world adapts to the reality that we 
> find ourselves in via normal market mechanics.  The problem with 
> proposing that connectivity for residential customers should be more 
> symmetrical is that its expensive, which is why we as operators didn't 
> roll it out that way to start.  We also don't see consumer demand for 
> symmetrical connections and with the decline in peer to peer file 
> sharing we've actually seen a decrease the ratio of used upstream 
> bandwidth (though not a decrease in absolute terms).
>
> I would like to deliver symmetrical bandwidth to all consumers just so 
> those few customers who need it today would have lower bills but 
> trying to justify that to our CFO without being able to point to an 
> increase in revenue either because of more revenue per sub or more 
> subs is a very tough task.  I don't believe my situation is uncommon.
>
>
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>
>
> On Fri, May 16, 2014 at 1:20 PM, Blake Hudson <blake () ispn net 
> <mailto:blake () ispn net>> wrote:
>
>     Thanks for the insight Scott. I appreciate the experience and
>     point of view you're adding to this discussion (not just the
>     responses to me). While I might be playing the devil's advocate
>     here a bit, I think one could argue each of the points you've made
>     below.
>
>     I do feel that general usage patterns are a reflection of the
>     technologies that have traditionally been available to consumers.
>     New uses and applications would be available to overcome hurdles
>     if the technologies had developed to be symmetrical. I'm not
>     saying that the asymmetrical choice was a bad one, but it was not
>     without consequences. If residential ISPs sell asymmetric
>     connections for decades, how can the ISP expect that application
>     developers would not take this into account when developing
>     applications? I don't think my application would be very
>     successful if it required X Mbps and half of my market did not
>     meet this requirement. Of course content/service providers are
>     going to tailor their services based around their market.
>
>     --Blake
>
>     Scott Helms wrote the following on 5/16/2014 12:06 PM:
>
>         Blake,
>
>         I might agree with your premise if weren't for a couple of items.
>
>         1)  Very few consumers are walking around with a HD or 4K
>         camera today.
>
>         2)  Most consumers who want to share video wouldn't know how
>         to host it themselves, which isn't an insurmountable issue but
>         is a big barrier to entry especially given the number of
>         NAT'ed connections.  I think this is much more of a problem
>         than available bandwidth.
>
>         3)  Most consumers who want to share videos seem to be
>         satisfied with sharing via one of the cloud services whether
>         that be YouTube (which was created originally for that use),
>         Vimeo, or one of the other legions of services like DropBox.
>
>         4)  Finally, upstream bandwidth has increased on many/most
>         operators.  I just ran the FCC's speedtest (mLab not Ookla)
>         and got 22 mbps on my residential cable internet service.  I
>         subscribe to one of the major MSOs for a normal residential
>         package.
>
>
>         Scott Helms
>         Vice President of Technology
>         ZCorum
>         (678) 507-5000 <tel:%28678%29%20507-5000>
>         --------------------------------
>         http://twitter.com/kscotthelms
>         --------------------------------
>
>
>         On Fri, May 16, 2014 at 12:38 PM, Blake Hudson <blake () ispn net
>         <mailto:blake () ispn net> <mailto:blake () ispn net
>         <mailto:blake () ispn net>>> wrote:
>
>             Certainly video is one of the most bandwidth intensive
>             applications. I don't deny that a < 1 Mbps video call is
>         both less
>             common and consumes less bandwidth than an 8Mbps HD stream.
>             However, if Americans had access to symmetric connections
>         capable
>             of reliably making HD video calls (they don't, in my
>         experience),
>             we might be seeing video calls as a common occurrence and
>         not a
>             novelty. I think the state of usage is a reflection on the
>             technology available.
>
>             If the capability was available at an affordable price to
>             residential consumers, we might see those consumers stream
>         movies
>             or send videos from their home or mobile devices via their
>             internet connection directly to the recipient rather than
>         through
>             a centralized source like Disney, NetFlix, Youtube, etc. Video
>             sharing sites (like youtube, vimeo, etc) primary reason for
>             existence is due to the inability of the site's users to
>             distribute content themselves. One of the hurdles to
>         overcome in
>             video sharing is the lack of availability in affordable
>         internet
>             connectivity that is capable of sending video at reasonable
>             (greater than real time) speeds.
>
>             --Blake
>
>             Scott Helms wrote the following on 5/16/2014 11:02 AM:
>
>                 Blake,
>
>                 None of those applications come close to causing
>         symmetrical
>                 traffic patterns and for many/most networks the upstream
>                 connectivity has greatly improved.  Anything related
>         to voice
>                 is no more than 80 kbps per line, even if the SIP traffic
>                 isn't trunked (less if it is because the signaling data is
>                 shared).  Document sharing is not being impinged, on my
>                 residential account right now I've uploaded about 30
>         documents
>                 this morning including large PDFs and Power Point
>         presentations.
>
>                 Off site back up is one use that could drive traffic,
>         but I
>                 don't believe that the limiting factor is bandwidth.  We
>                 looked at getting into that business and from what we
>         saw the
>                 limiting factor was that most residential and SOHO
>         accounts
>                 didn't want to pay enough to cover your storage &
>         management
>                 costs.  In our analysis the impact of bandwidth on the
>                 consumer side adoption was basically zero.  There is no
>                 expectation that back ups run instantly.  Having said
>         all of
>                 that, even if hosted back up became wildly popular
>         would not
>                 change the balance of power because OTT video is both
>         larger,
>                 especially for HD streams, and used much more frequently.
>
>
>                 Scott Helms
>                 Vice President of Technology
>                 ZCorum
>         (678) 507-5000 <tel:%28678%29%20507-5000>
>         <tel:%28678%29%20507-5000>
>                 --------------------------------
>         http://twitter.com/kscotthelms
>                 --------------------------------
>
>
>                 On Fri, May 16, 2014 at 11:53 AM, Blake Hudson
>         <blake () ispn net <mailto:blake () ispn net>
>                 <mailto:blake () ispn net <mailto:blake () ispn net>>
>         <mailto:blake () ispn net <mailto:blake () ispn net>
>                 <mailto:blake () ispn net <mailto:blake () ispn net>>>> wrote:
>
>
>                     Jay Ashworth wrote the following on 5/16/2014
>         10:35 AM:
>
>                         ----- Original Message -----
>
>                             From: "Mark Tinka" <mark.tinka () seacom mu
>         <mailto:mark.tinka () seacom mu>
>                 <mailto:mark.tinka () seacom mu
>         <mailto:mark.tinka () seacom mu>>
>                             <mailto:mark.tinka () seacom mu
>         <mailto:mark.tinka () seacom mu>
>                 <mailto:mark.tinka () seacom mu
>         <mailto:mark.tinka () seacom mu>>>>
>                             While that is true a lot of the time
>         (especially
>                 for eyeball
>                             networks), it is less so now due to social
>         media.
>                 Social
>                             media forces the use of symmetric
>         bandwidth (like
>                 FTTH),
>                             putting even more demand on the network,
>
>                         Oh yes; clearly, Twitter will be the end of L3.
>
>                         :-)
>
>                         Could you expand a bit, Mark on "Social media
>         forces
>                 the use
>                         of symmetric
>                         bandwidth"?  Which social media platform is it
>         that
>                 you think
>                         has a)
>                         symmetrical flows that b) are big enough to
>         figure into
>                         transit symmetry?
>
>                         Cheers,
>                         -- jra
>
>                     Applications like Skype and Facetime (especially
>                 conference calls)
>                     would be one example where an application benefits
>         from
>                 symmetric
>                     (or asymmetric in favor of higher upload speed)
>         connectivity.
>                     Cloud office applications like storage of documents,
>                 email, and
>                     IVR telephony also benefit from symmetrical
>         connectivity.
>                 Off-site
>                     backup software is another great example. Most
>         residential
>                     connections are ill suited for this. I believe these
>                 applications
>                     (and derivatives) would be more popular today if the
>                 connectivity
>                     was available.
>
>                     --Blake