Music Freedom is a little different, at least in theory. Theory is always cleaner than reality so let's start there.
In theory, Music Freedom is a way to have all streaming music traffic not count toward your data cap. If that's the case, T-Mobile is discriminating based on the type of traffic, but not the origin of the traffic. Generally speaking, network management and traffic shaping aren't being fought against by net neutrality campaigners. It makes sense that VoIP traffic receive higher priority than FTP because if my FTP transfer takes another 10 seconds out of 5 minutes I'll hardly notice, but if my voice traffic stutters, I will certainly notice.
In many ways, Music Freedom is an extension of this to bandwidth caps. Streaming music is low, consistent bandwidth usage, but not real-time. By contrast, loading things on the web is high bandwidth usage, but quite spiky. As a carrier and as a user, it would make sense to reschedule music packets around web packets. If the next 15 seconds of the song are already in your local buffer, you'd much rather it wait until you're idle in your browsing session than slow down your browsing - so long as the next second of music is delivered less than 15 seconds from now.
If T-Mobile were simply managing its network this way, I don't think anyone would have a problem with it. Music lovers wouldn't notice that things were being scheduled for more idle times in the network and web users would see faster speeds. That's simply an equal or better outcome for everyone.
Traffic shaping is a good thing. My university has a wonderfully progressive IT department and didn't want to block anything. However, out of 5,000 users, the top 50 users use half the bandwidth. Again, the university doesn't mind that. Most of the time it doesn't matter. However, they didn't want students trying to do research to have their relatively low-bandwidth web traffic stifled by students file sharing and so web traffic was given greater priority than file sharing. The university didn't want to block file sharing, but I think a lot of people would recognize that large file transfers are not as time-sensitive as interactive processes.
Some people suggest that all data be treated the same. I don't think that's the answer. Some traffic needs more real-time guarantees than others. That's very different from discriminating based on the source/destination of the traffic.
But T-Mobile is applying this to data caps (or throttling points). I'm going to argue that (on an intelligently designed system) using 1GB of streaming music is less network usage than downloading a 1GB file. What do I mean by less network usage? I mean that the streaming music usage impacts other users on the same connection less. For a simple example, let's say that you're browsing the web and I'm streaming 256kbps music over a 512kbps connection. Are we both using half of the connection? No. When browsing the web, you have peaks and valleys in your data transmission. To make things simple, let's say that every time you click a link you download 64KB or 512kbits. If I'm using half the connection, it takes 2 seconds for you to download. But that's not very efficient. I already have the next few seconds of the song in my buffer so it makes more sense for me to drop down to 0kbps for a second, you to complete your download in 1 second, and then for me to download 2 seconds of song in the second after your download completes. I have not seen any degradation of my service - I'm oblivious to it happening. Downloading the song faster doesn't help me, but you downloading your web page faster does help you.
So, by being able to reschedule streaming music around other traffic, it actually uses less of the network capacity during the periods when there is contention. In total, it uses the same amount in terms of MB or GB transferred. However, you don't care how much of the connection I'm using when you're not using it. You only care how much I'm using while you want your downloads to go faster. If I were only using traffic during the valleys of your transmissions, it would be like I was never using the connection from your perspective. So, me streaming music affects you less because we know that we can reschedule things within certain bounds.
There's a bit of a disconnect between pricing and usage. If you're using the network at 3am, your data usage probably isn't significant. Netflix refills its content caching boxes during times where network traffic is more idle because it isn't just about bytes transferred, but whether other people are trying to use the link's capacity at the same time you are. However, coming up with a pricing model that accurately models one's usage of a link's capacity as a function of contesting for that capacity from other users would be hard to come up with. Again, if I'm sharing a link with 100 other people and agree only to use the link when no one else wants to (ie, they aren't sending/receiving packets), then I'm never contesting anyone else for link capacity. By the way, I'm not saying that's a practical standpoint, just an illustrative thing.
If 1GB of streaming music is actually using up less of the network, why should it be charged the same? GBs of transfer is really just a proxy for what is actually cared about. In many cases, it's reasonable. We can't tell if you care whether that web page loads as fast as possible or whether that FTP transfer takes an additional minute or not. But we can say (with reasonably high confidence) that you don't care if the 30th second of a song arrives within 5 seconds of the transfer starting or 20 seconds of the transfer starting. As such, it's possible that we can reschedule streaming music in such a way that it's basically not using the network - at least not at times when other users care. Network capacity used when there's excess capacity other users don't want isn't really network capacity that's being used. It's simply filling what would be dead space.
If bandwidth caps/charges are supposed to make sure that high users pay for the capacity increases they necessitate or make sure that they don't crowd out smaller users, then shouldn't usage that might be high in GBs transferred, but is actually not requiring capacity increases or harming other users get a bit of an exemption?
Now, in practice, T-Mobile doesn't support all providers and that is concerning. It would be nice if they posted an explanation of their criteria rather than just saying "email us if you're on the inside". Likewise, it being free rather than a discounted rate based on how much it impacts can be concerning. Others can talk about the practice and the issues there because this comment is already too long.
tl;dr: GBs transferred is not exactly equal to network usage. Streaming music can actually use less of a network link's capacity than GBs transferred would make it seem because it can be rescheduled for times when the network is seeing less traffic and, therefore, not impacting users.
Well, the flip side is, why does only music get this benefit? What if I didn't care if my 50mb download takes 10 times as long? Wouldn't it then fall under the same kind of "using dead time" thing?
All t-mobile plans that qualify for free music streaming are "unlimited" in that after you reach your data allotment it does just that -- cuts bandwidth by an order of magnitude. Its entirely possible that it works the same way as is suggested above.
In theory, Music Freedom is a way to have all streaming music traffic not count toward your data cap. If that's the case, T-Mobile is discriminating based on the type of traffic, but not the origin of the traffic. Generally speaking, network management and traffic shaping aren't being fought against by net neutrality campaigners. It makes sense that VoIP traffic receive higher priority than FTP because if my FTP transfer takes another 10 seconds out of 5 minutes I'll hardly notice, but if my voice traffic stutters, I will certainly notice.
In many ways, Music Freedom is an extension of this to bandwidth caps. Streaming music is low, consistent bandwidth usage, but not real-time. By contrast, loading things on the web is high bandwidth usage, but quite spiky. As a carrier and as a user, it would make sense to reschedule music packets around web packets. If the next 15 seconds of the song are already in your local buffer, you'd much rather it wait until you're idle in your browsing session than slow down your browsing - so long as the next second of music is delivered less than 15 seconds from now.
If T-Mobile were simply managing its network this way, I don't think anyone would have a problem with it. Music lovers wouldn't notice that things were being scheduled for more idle times in the network and web users would see faster speeds. That's simply an equal or better outcome for everyone.
Traffic shaping is a good thing. My university has a wonderfully progressive IT department and didn't want to block anything. However, out of 5,000 users, the top 50 users use half the bandwidth. Again, the university doesn't mind that. Most of the time it doesn't matter. However, they didn't want students trying to do research to have their relatively low-bandwidth web traffic stifled by students file sharing and so web traffic was given greater priority than file sharing. The university didn't want to block file sharing, but I think a lot of people would recognize that large file transfers are not as time-sensitive as interactive processes.
Some people suggest that all data be treated the same. I don't think that's the answer. Some traffic needs more real-time guarantees than others. That's very different from discriminating based on the source/destination of the traffic.
But T-Mobile is applying this to data caps (or throttling points). I'm going to argue that (on an intelligently designed system) using 1GB of streaming music is less network usage than downloading a 1GB file. What do I mean by less network usage? I mean that the streaming music usage impacts other users on the same connection less. For a simple example, let's say that you're browsing the web and I'm streaming 256kbps music over a 512kbps connection. Are we both using half of the connection? No. When browsing the web, you have peaks and valleys in your data transmission. To make things simple, let's say that every time you click a link you download 64KB or 512kbits. If I'm using half the connection, it takes 2 seconds for you to download. But that's not very efficient. I already have the next few seconds of the song in my buffer so it makes more sense for me to drop down to 0kbps for a second, you to complete your download in 1 second, and then for me to download 2 seconds of song in the second after your download completes. I have not seen any degradation of my service - I'm oblivious to it happening. Downloading the song faster doesn't help me, but you downloading your web page faster does help you.
So, by being able to reschedule streaming music around other traffic, it actually uses less of the network capacity during the periods when there is contention. In total, it uses the same amount in terms of MB or GB transferred. However, you don't care how much of the connection I'm using when you're not using it. You only care how much I'm using while you want your downloads to go faster. If I were only using traffic during the valleys of your transmissions, it would be like I was never using the connection from your perspective. So, me streaming music affects you less because we know that we can reschedule things within certain bounds.
There's a bit of a disconnect between pricing and usage. If you're using the network at 3am, your data usage probably isn't significant. Netflix refills its content caching boxes during times where network traffic is more idle because it isn't just about bytes transferred, but whether other people are trying to use the link's capacity at the same time you are. However, coming up with a pricing model that accurately models one's usage of a link's capacity as a function of contesting for that capacity from other users would be hard to come up with. Again, if I'm sharing a link with 100 other people and agree only to use the link when no one else wants to (ie, they aren't sending/receiving packets), then I'm never contesting anyone else for link capacity. By the way, I'm not saying that's a practical standpoint, just an illustrative thing.
If 1GB of streaming music is actually using up less of the network, why should it be charged the same? GBs of transfer is really just a proxy for what is actually cared about. In many cases, it's reasonable. We can't tell if you care whether that web page loads as fast as possible or whether that FTP transfer takes an additional minute or not. But we can say (with reasonably high confidence) that you don't care if the 30th second of a song arrives within 5 seconds of the transfer starting or 20 seconds of the transfer starting. As such, it's possible that we can reschedule streaming music in such a way that it's basically not using the network - at least not at times when other users care. Network capacity used when there's excess capacity other users don't want isn't really network capacity that's being used. It's simply filling what would be dead space.
If bandwidth caps/charges are supposed to make sure that high users pay for the capacity increases they necessitate or make sure that they don't crowd out smaller users, then shouldn't usage that might be high in GBs transferred, but is actually not requiring capacity increases or harming other users get a bit of an exemption?
Now, in practice, T-Mobile doesn't support all providers and that is concerning. It would be nice if they posted an explanation of their criteria rather than just saying "email us if you're on the inside". Likewise, it being free rather than a discounted rate based on how much it impacts can be concerning. Others can talk about the practice and the issues there because this comment is already too long.
tl;dr: GBs transferred is not exactly equal to network usage. Streaming music can actually use less of a network link's capacity than GBs transferred would make it seem because it can be rescheduled for times when the network is seeing less traffic and, therefore, not impacting users.