I have seen suggestions that switching to MLPPP service would somehow enable one to side-step Bell's traffic shaping and presumably any other non-neutral network management they might be doing. Is this true?  I would have thought that MLPPP traffic traverses the same Gateway Access Service as everything else and would get just as throttled.  How does MLPPP change anything? ____________________________________________________________________ Gardner Buchanan                         gbuchana(a)teksavvy(dot)com                                  FreeBSD: Where you want to go. Today.

How does MLPPP change anything? MLPPP is really PPPoE with a couple extra bytes in the header before the payload. So to Bell, it looks like PPPoE and it processes it like PPPoE. But its DPI equipment is programmed to peek at specific locations in the packet payload for certain strings/values. So with MLPPP adding (I think) 6 bytes to the header, the packet payload is 6 bytes further from the start of packet, so the DPI equipment does not find the various signatures it is looking for. If Bell's DPI equipment looks for a 19 byte string Bittorrent Protocol at byte 63 of the PPPoE packet, when you use MLPPP, the DPI equipment would see *&?!& Bittorrent Pr and thus not recognize that packet as being the opening salvo in a BitTorrent exchange.

But its DPI equipment is programmed to peek at specific locations in the packet payload for certain strings/values. So you're saying that the equipment Bell is using either cannot (yet) or has been (so far) programmed not to mess with MLPPP traffic.  It seems still within theoretical possibility and even reasonable liklihood that Bell would configure or upgrade their equipment to interfere with MLPPP on the GAS too. ____________________________________________________________________ Gardner Buchanan                         gbuchana(a)teksavvy(dot)com                                  FreeBSD: Where you want to go. Today.

So you're saying that the equipment Bell is using either cannot (yet) or has been (so far) programmed not to mess with MLPPP traffic. Correct. Bell likely had to pay Ellacoya/Arbor some big money to have them develop the capability to parse  a TCP packet in an IP packet in a PPPoE packet in an L2TP packet which is what its devices have to do when dealing with GAS traffic. For Sympatico traffic, the DPI boxes het IP packets. Bell would probably have to pay Ellacoya to develop additional filters to spot signatures in different locations of packets when there is MLPPP and Bell so far has not done so. Should Bell's throttling rights be reconfirmed at the conclusion of all the issues at the CRTC right now, perhaps Bell might spend the money to catch MLPPP. However, it is also quite possible that MLPPP traffic is small enough that it really isn't worth it for them at this point in time. But should it grow and become important, then it might be a different story. Should the CRTC come to its senses and declare that throttling is not legal on GAS service, then all this is moot and MLPPP will be relegated to a very obscure niche of people bonding multiple lines together.

Bell likely had to pay Ellacoya/Arbor some big money to have them develop the capability It would surprise me very much that the DPI vendors did not already have such a feature.  PPPOE is a pretty common _link_ tunneling protocol and I bet handling it and maybe even MLPPP is a feature that the vendor would add of their own accord, _base_d on demand. Unpacking protocol _layer_s is not that hard a problem, even at speed, and it does not have to be 100% accurate