Network Neutrality

I was reading an finncrypt() article about impending violation of network neutrality in Europe and found it largely humorous. Network hasn't been neutral since introduction of QoS (i.e. ever) and only easy and fast way to make net neutral is to remove QoS everywhere, which would serve benefit of ideology only, not benefit of any single individual, some services that work today, simply would stop working.

In real life operators use QoS to prioritise VAS they offer, such as VoIP or IP-TV, if we follow network neutrality principles we should guarantee same level of service to VoIP and IP-TV provided by 3d parties also. This is not done today, but it is not to protect your competitiveness, rather it is not done because there is no obvious technical way to do it.

When network neutrality is broken in scenario above operator typically gives higher priority to certain IP addresses which are used to provide the VAS, to be able to do this in a network neutral way, operator or rather the network devices would need to know which IP addresses are important to this given end user, which should get preferential treatment. Operator nor device can magically know these and this is where the problem lies.

Obvious solution to many is TOS (Type Of Service) field in IP packet frame, here you can tell what type of treatment given packet should receive, so end user can dictate which packets are important to her and which are not, remote end will honour the TOS and reply with same TOS value set. Alas, this will not work, between different AS (operators)  often TOS byte is zeroed out, if this would not be done in pure IP backbones no QoS would work today, as single remote AS could fill the priority queues with trash, breaking not only QoS between these two operators but indeed even the QoS inside the one operator which works today.

Say end user marks skype packet as priority packet, all good, they can prioritise it over their DSL line to operator, but when it starts transiting via other operators network there is high chance that somewhere down the line the TOS byte is zeroed out, then the reply skype packet isn't marked as priority packet and it cannot be treated preferentially when sending the data over the DSL to the end user.

Technically there is no particular reason for operator to attempt stop last mile from preferring any packets end users request, only problem is the information is lost in transit and it is not a problem which there is simple and fast solution.

We can make surprisingly good prediction on what is preferential traffic and what is not by simply looking at packet size, if we would prefer packets which are say 200 bytes or less, it would have immediate and quite large effect on perceived quality of Internet.

You can observe this problem easily on your home DSL by sending large files, like pictures to Internet and attempting to use some latency critical service at same time like ssh, VoIP or online gaming, experience will be terrible for duration of upload. Even non-latency critical like download or buffered music streaming suffers due to upstream TCP ACK being dropped in queue.

In many ways this is the proverbial silver bullet, it is extremely simple, doesn't change from customer and customer and effects are immediately visible, you can continue online gaming while torrenting. Only downside with this is, most DSLAM/MSAN/CMTS devices at operator do not actually support preferring packets based on their size.

Solution might be new protocol CQSP (Customer QoS signalling Protocol) which could instruct both CPE and DSLAM/MSAN/CMTS about networks which should be prioritized, this way when you'd install skype, it would automatically use CQSP to configure required settings. This is deployable today, requires only software updates. Hoping that TOS would work across Internet any time soon is not realistic nor is updating DSLAM/MSAN/CMTS hardware to version which would support packet size based QoS.