How about a system where I tell my customers that for a given plan X at price Y they get U bytes of "high priority" upload per month (or day or whatever) and after that all their traffic is low priority until the next cycle starts.  
<br><br>Now here's the fun part.  They can mark the priority on the packets they send (diffserv/TOS) and decide what they want treated as high priority and what they want treated as not-so-high priority.<br><br>If I'm a low usage customer with no p2p applications, maybe I can mark ALL my traffic high priority all month long and not run over my limit.  If I run p2p, I can choose to set my p2p software to send all it's traffic marked low priority if I want to, and save my high priority traffic quote for more important stuff.
<br><br>Maybe the default should be high priority so that customers who do nothing but are light users get the best service.<br><br>low priority upstream traffic gets dropped in favor of high priority, but users decide what's important to them.
<br><br>If I want all my stuff to be high priority, maybe there's a metered plan I can sign up for so I don't have any hard cap on high priority traffic each month but I pay extra over a certain amount.<br><br>This seems like it would be reasonable and fair and p2p wouldn't have to be singled out.
<br><br>Any thoughts?<br><br><div><span class="gmail_quote">On 10/22/07, <b class="gmail_sendername">Joe Greco</b> <<a href="mailto:jgreco@ns.sol.net">jgreco@ns.sol.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> I wonder how quickly applications and network gear would implement QoS<br>> support if the major ISPs offered their subscribers two queues: a default<br>> queue, which handled regular internet traffic but squashed P2P, and then a
<br>> separate queue that allowed P2P to flow uninhibited for an extra $5/month,<br>> but then ISPs could purchase cheaper bandwidth for that.<br>><br>> But perhaps at the end of the day Andrew O. is right and it's best off to
<br>> have a single queue and throw more bandwidth at the problem.<br><br>A system that wasn't P2P-centric could be interesting, though making it<br>P2P-centric would be easier, I'm sure.  ;-)<br><br>The idea that Internet data flows would ever stop probably doesn't work
<br>out well for the average user.<br><br>What about a system that would /guarantee/ a low amount of data on a low<br>priority queue, but would also provide access to whatever excess capacity<br>was currently available (if any)?
<br><br>We've already seen service providers such as Virgin UK implementing things<br>which essentially try to do this, where during primetime they'll limit the<br>largest consumers of bandwidth for 4 hours.  The method is completely
<br>different, but the end result looks somewhat similar.  The recent<br>discussion of AU service providers also talks about providing a baseline<br>service once you've exceeded your quota, which is a simplified version of
<br>this.<br><br>Would it be better for networks to focus on separating data classes and<br>providing a product that's actually capable of quality-of-service style<br>attributes?<br><br>Would it be beneficial to be able to do this on an end-to-end basis (which
<br>implies being able to QoS across ASN's)?<br><br>The real problem with the "throw more bandwidth" solution is that at some<br>point, you simply cannot do it, since the available capacity on your last<br>mile simply isn't sufficient for the numbers you're selling, even if you
<br>are able to buy cheaper upstream bandwidth for it.<br><br>Perhaps that's just an argument to fix the last mile.<br><br>... JG<br>--<br>Joe Greco - <a href="http://sol.net">sol.net</a> Network Services - Milwaukee, WI - 
<a href="http://www.sol.net">http://www.sol.net</a><br>"We call it the 'one bite at the apple' rule. Give me one chance [and] then I<br>won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
<br>With 24 million small businesses in the US alone, that's way too many apples.<br></blockquote></div><br>