Re: Binge On! - And So This is Net Neutrality?

[Owen DeLong <owen () delong com>]

> On Nov 23, 2015, at 14:58 , Mark Andrews <marka () isc org> wrote:
>
>
> In message <E24772E7-A95B-4866-9630-2B1023EBD4FD () delong com <mailto:E24772E7-A95B-4866-9630-2B1023EBD4FD () delong 
> com>>, Owen DeLong write
> s:
> > > On Nov 23, 2015, at 14:16 , Christopher Morrow
> > <morrowc.lists () gmail com> wrote:
> > > On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong <owen () delong com> wrote:
> > > > Except there’s no revenue share here. According to T-Mobile, the
> > streaming partners
> > > > aren’t paying anything to T-Mo and T-Mo isn’t paying them. It’s kind
> > of like zero-rating
> > > > in that the customers don’t pay bandwidth charges, but it’s different
> > in that the service
> > > > provider isn’t being asked to subsidize the network provider (usual
> > implementation of
> > > > zero-rating).
> > >
> > > equal exchange of value doesn't have to be dollars/pesos/euros
> > > changing hands right?
> > > -chris
> >
> > Sure, but I really don’t think there’s an exchange per se in this case,
> > given that T-Mo
> > is (at least apparently) willing to accommodate any streaming provider
> > that wants to
> > participate so long as they are willing to conform to a fairly basic set
> > of technical criteria.
>
> No. This is T-Mo saying they are neutral but not actually being so.
> This is like writing a job add for one particular person.
>
> Its just as easy to identify a UDP stream as it is a TCP stream.
> You can ratelimit a UDP stream as easily as a TCP stream.  You can
> have congestion control over UDP as well as over TCP.  Just because
> the base transport doesn't give you some of these and you have to
> implement them higher up the stack is no reason to throw out a
> transport.

Are there a significant number (ANY?) streaming video providers using UDP
to deliver their streams?

I admit I’m mostly ignorant here, but at least the ones I’m familiar with all use TCP.

Further, it depends on how you define a stream…

If a stream is a conversation between two particular endpoints using consistent
port numbers, then sure, it’s (somewhat) easy to identify, except…

OTOH, if a stream is considered all of the packets involved in a particular user
watching a particular video, then depending on implementation, this could be much
harder to identify over UDP than TCP.

For example, if the stream is delivered via a torrent-like delivery system over UDP,
it could be very hard to identify that all the various seemingly random UDP packets
are part of that particular video delivery.

If the requirements were specific enough that they matched a particularly small
subset of video delivery services, then I might agree with you. In this case, they
seem to have been written more from the technical limitations of T-Mobiles current
ability to identify the traffic than targeted at a specific service.

For example, I seriously doubt that video delivered from http://us-st.xhcdn.com/swf/ <http://us-st.xhcdn.com/swf/>…
is likely to be among their “target candidates”. Nonetheless, it does appear that if
xhcdn chooses to apply under the program, they wouldn’t have any trouble meeting
the requirements. (if you want to review the kind of videos hosted on xhcdn, visit
their client www.xhamster.com <http://www.xhamster.com/>. Warning… NSFW)

You can make all the claims you want about how they should have or could have
implemented this, but unless you have evidence that the issue is actually an
attempt to circumvent the intent of net neutrality and not merely a technical
limitation of their particular implementation, then I really don’t think you have
a basis for your claim above.

Owen