Load balancers can insert cookies to identify clients uniquely. (That solves the proxy/single-ip-multiple-clients problem - multiple clients from one proxy IP can still be uniquely tracked this way.) The newer load balancers (F5/iRules for e.g.) are also capable of doing per resource, per client throttling using the inserted cookies or session table.
Server side state per client is insane. Pushing it client side would be what, a kb? Wih an average object size of 50kb that's 2%. I doubt CDN customers would be willing to take a 2% cost hit for this feature.
Now, assume we solve all that. The state is pushed on the client. The performance hit is so small as to be free. And the CDN eats the dev and opex. So what does the CDN do when "bad" range requests are detected? Throw a 400? What customer is willing to break all IOS 6 clients?
For starters, average podcast download is 40Mb or so. More than 50Kb in any case. Next maintaining state per client isn't anything new - it might not be ideal for CDNs but many LBs keep state for things such as maintaining session persistence etc.
If there is a potential for clients intentionally or unintentionally jacking up your CDN bill - I am sure somebody has a solution to prevent it - especially since money is at stake.
You laughed at iRules - I got that part, but what about iRules doing HTTP Request throttling? Far as I know it can do that based on source ip and port, uri etc. which should work for this kind of scenario with some modifications.
Your average podcast source material may be 40mb. Clients will most assuredly not be fetching that all in single request. Your state transfer overhead is per request. The 50kb estimate is an educated guess at the average size of an http response from a CDN. You have to keep state on every request, otherwise how can you detect your "bad request" patterns. Now, you could only stick your state on to Range'd requests. But a lot (most?) of the customers affected by this are doing a significant portion of requests as ranges already.
IRules, specifically, don't work for any reasonable packet rate. Every request must now come off the nic, across the bus, hit CPU, hit a few times memory, and back. Tracking state, in general, kills packet rates. There's no guarantee that your flow is going to be hitting the same interface, interrupt, processor, or even host. At every one of those levels shared state dramatically increases complexity and reduces your max possible packet rate. Silicon really can't flip bits that quickly.
Which gets us back to the business question. So you've found a "bad" client. What aceptable action can you take? Throttle all iOS 6 users? Throw 400s?
To be honest here this excess cost is going to be absorbed in three places. 1) end users will suck it up in data charges because they have no alternative 2) sites will eat the bandwidth charges. They can't passit on if they have no directly associated revenue. Or they don't want to lose customers. 3) CDN/providers will take a relatively small hit issuing credits to keep their customers happy.
Notice who won't lose a cent here? Apple and other broken client providers.