[186886] in North American Network Operators' Group
Re: Binge On! - get your umbrellas out, stuff's hitting the fan.
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Jan 8 12:11:54 2016
X-Original-To: nanog@nanog.org
Date: Fri, 8 Jan 2016 09:11:51 -0800
From: Hugo Slabbert <hugo@slabnet.com>
To: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
In-Reply-To: <11769.1452224600@turing-police.cc.vt.edu>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu 2016-Jan-07 22:43:20 -0500, Valdis Kletnieks <Valdis.Kletnieks@vt.ed=
u> wrote:
>So we went round and round back in November regarding Binge On! and whether
>it was net neutrality. So here's some closure to that...
>
>The EFF did some testing and discovered that what T-Mobile is actually doi=
ng
>doesn't match what they said it was...
>
>https://www.eff.org/deeplinks/2016/01/eff-confirms-t-mobiles-bingeon-optim=
ization-just-throttling-applies
>
>Apparently, John Legere, CEO of T-Mobile, doesn't know who the EFF is,
>or why they're giving him a hard time.
>
>"Part B of my answer is, who the fuck are you, anyway, EFF?" Legere said. =
"Why
>are you stirring up so much trouble, and who pays you?"
>
>http://www.theverge.com/2016/1/7/10733298/john-legere-binge-on-lie
>
>/me makes popcorn....
And I'm sorry, but this line from Legere had me raging at my screen:
"There are people out there saying we=E2=80=99re =E2=80=9Cthrottling.=E2=80=
=9D They=E2=80=99re playing=20
semantics! Binge On does NOT permanently slow down data nor remove customer=
=20
control. Here=E2=80=99s the thing, mobile customers don=E2=80=99t always wa=
nt or need giant=20
heavy data files. So we created adaptive video technology to optimize for=
=20
mobile screens and stream at a bitrate designed to stretch your data=20
(pssst, Google, that's a GOOD thing)."[1]
=2E..so...you're "optimizing" the bitrate of video traffic for mobile by=20
lowering it to 1.5 mbps, but don't worry: it's not "throttling". And you're=
=20
accusing the "other guys" of playing semantics? Beside pure marketing=20
doublespeak, I don't even know what actual logic he's using here. =20
Apparently it's only "throttling" if it *permanently* slows down traffic,=
=20
and BingeOn somehow doesn't do that (besides what the EFF is putting=20
forward)? Is it because even though it's enabled by default, there is=20
still an "off" switch, and therefore user choice is maintained (though=20
probalby not obvious to most consumers)?
Listen: I have no issue with doing shaping or traffic prioritization or=20
whatever as your customer asks for it; we offer that as an option to=20
customers to get the most out of their connections and I'm sure many of you=
=20
do as well. But:
1) Those are done at the request of the customer, not opt-out.
2) Be honest about what you're doing.
T-Mobile seems to be trying to spin this as if they have some magical=20
technology that will re-encode streaming video on the fly to 480p, when=20
really they're just ID-ing video and rate-limiting it (when it comes to=20
video that doesn't match their technical requirements doc and doesn't do=20
ABR down to 480p on the sending side). Fine: just getting decent accuracy=
=20
on various edge cases of identifying video traffic isn't trivial, so kudos,=
=20
but don't blow smoke about it. If Legere has some info about how this=20
truly at a technical level is not just rate limiting, then show us that=20
info. Yes: I've read the "Content Provider Technical Requirements" doc[2]=
=20
that talks about adaptive bitrate tech on the sending side:
"The content provider will provide video over T=E2=80=90Mobile=E2=80=99s ne=
twork using=20
adaptive bit rate technology in which the server sending streaming video=20
content will automatically adapt video resolution of the stream based on=20
the capabilities of the data connection or as otherwise indicated by the=20
T=E2=80=90Mobile network."
But, that's for the content folks that are participating in the BingeOn=20
setup for zero-rating. The EFF's data indicates that if you're just a=20
random video stream (or video media type file), you get rate limited.
With all of this said, I appreciate the challenge of getting something like=
=20
this implemented at scale without going opt-out. T-Mo is going for a PR=20
win as well as, let's be honest, reducing network utilization by reducing=
=20
the bitrate of video crossing the network, but it's *highly* unlikely that=
=20
you're going to get enough critical mass in an opt-in effort to pull it=20
off. To T-Mo's credit, they're making the opt-out quite simple, but let's=
=20
be clear that this is not a net neutral move if we go by the commonly=20
accepted definitions:
"The idea is that a maximally useful public information network aspires to=
=20
treat all content, sites, and platforms equally."[3]
"Net neutrality (also network neutrality, Internet neutrality, or net=20
equality) is the principle that Internet service providers and governments=
=20
should treat all data on the Internet the same, not discriminating or=20
charging differentially by user, content, site, platform, application, type=
=20
of attached equipment, or mode of communication."[4]
The majority of the "fight" to date has been about the source and origin of=
=20
the traffic, so the discussion often leans that direction, but there is no=
=20
question that BingeOn works to identify a specific application or type of=
=20
content (video) and then treats it differently from other traffic.
"So why are special interest groups -- and even Google! -- offended by=20
this? Why are they trying to characterize this as a bad thing?"
Because you're drawing a box within which people have to play, which puts=
=20
shackles on innovation. For traffic destined for a BingeOn enabled T-Mo=20
customer (which is everyone by default unless they opt out), content=20
providers can choose to:
1. Meet the technical requirements (possibly at real cost to them to adapt=
=20
their infrastructure) and do adaptive bitrate streaming, and get capped at=
=20
480p but be zero-rated.
2. Do nothing, don't get zero-rated, and get rate-limited to 1.5 mbps.
Part of the concern from the net neut crowd is that creating little boxes=
=20
like this hampers innovation and the development of novel new applications.=
=20
BingeOn in and of itself may not directly curtail innovation, but the=20
concern is that everyone can create their own little box with which content=
=20
providers need to cooperate/interoperate. Already in the BingeOn technical=
=20
requirements doc, there is reference to basically a business relationship=
=20
(e.g. "To ensure a good customer experience, any changes to a content=20
provider=E2=80=99s streaming formats and/or mechanisms that could impact T=
=E2=80=90Mobile=E2=80=99s=20
ability to include the provider=E2=80=99s content in the offering must be=
=20
communicated to T=E2=80=90Mobile in advance"). Do we really want a situati=
on where=20
content providers need to establish direct relationships with any edge=20
provider that runs a similar setup to BingeOn in order to ensure their=20
traffic doesn't get squashed or degraded?
My gut says that most edge operators wouldn't have an issue with the=20
practice of traffic prioritization or rate limiting as requested by=20
customers (e.g. prioritize my VoIP traffic; cap offsite backup or=20
replication traffic). But those are explicit customer-initiated requests. =
=20
I think it is legitimate to express concern when that type of traffic=20
classification and differential treatment is applied en masse. T-Mo (or at=
=20
least Legere) are pandering to "the little guy" and dismissing legitimate=
=20
reports as "bullshit" in a bunch of handwaving and PR. Let's have an=20
honest conversation about this, including who all stand to benefit and=20
where there is legitimate harm or cause for concern.
--=20
Hugo
hugo@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
(also on Signal)
[1]https://newsroom.t-mobile.com/issues-insights-blog/binge-on-update-blog.=
htm
[2]http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical=
-Criteria-November-2015.pdf
[3]http://www.timwu.org/network_neutrality.html
[4]https://en.wikipedia.org/wiki/Net_neutrality
--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJWj+3XAAoJEJqxD/2xeDE+1bcQAK/6mKBzpY5TfWFW+qBzuVCM
u+Qg1Wkr8e8Z3V58Ov9iUKyu66zNsfh6b1NdVzYbvpYgRmJXg8ayhIQPfdTbX3vp
79zm0WsJPrb1MO5ll/qgT4jLAYbn7noF3vLkxX1yWo+cYW0Og6XKnKreBvYarYsg
GOX1aq5qfhWs88y8EzzoyDYVMQQqdnrgfW5+qJSfcMr0f47zM9RxYN/hq96QBAtr
uexJ6/2b2JDlZ+oDUcYafZVQ11+qT0DxuZwvLPv4DLimwcI/8QA9+y5vzDMdqryI
iO88MsoSbDrrkmGupMue5gGx+38YgoBKjuu9DuUoacCZ5x9jgcvFjncifSjemfqS
gPszMRtvly9lyPsdYPnbDT7W1evDDcOGXcSqtc/Kn34ulnDMfKYEHQ1SrPQx10wa
343didE2wyaXD8sldcYZZdtHAZpV1WcllnqSMERbQT1riQhaghkWy3Pnpp3cCruP
sC3vwAfM8n6hgVKlCpdQ781UgQqW0TUGXJ44uDfbtFUPvWIJjpOuxb/Tr1xsV1ZF
kClR9r7WCAYWuUio9R8X+hNjAtPMWhF2oXGmOwK2velMGDIuwLLvHKjwtSpghbm5
sta0s4X2Rq2EOBqakSvkYSF5IyXdSHTEEaDuWu+aZXjJaPE2myGq5vamtmYOeCem
k/VTdv+gA432CkjiDHm4
=QAP/
-----END PGP SIGNATURE-----
--J2SCkAp4GZ/dPZZf--
