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