[100482] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: BitTorrent swarms have a deadly bite on broadband nets

daemon@ATHENA.MIT.EDU (Frank Bulk)
Wed Oct 24 10:49:02 2007

Reply-To: <frnkblk@iname.com>
From: "Frank Bulk" <frnkblk@iname.com>
To: "'Dorn Hetzel'" <dhetzel@gmail.com>, "Joe Greco" <jgreco@ns.sol.net>
Cc: <nanog@merit.edu>
In-Reply-To: <2ee691ff0710240612q1919358dj94c41a4d115217ad@mail.gmail.com>
Date: Wed, 24 Oct 2007 09:15:20 -0500
Errors-To: owner-nanog@merit.edu


This is a multipart message in MIME format.

------=_NextPart_000_00AC_01C8161E.668B3C10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The key thing is that it can't be too complicated for the subscriber.  What
you've described is already too difficult for the masses to consume.  

 

The scavenger class, as has been described in other postings, is probably
the simplest way to implement things.  Let the application developers take
care of the traffic marking and expose priorities in the GUI, and the
marketing from the MSO needs to be "$xx.xx per month for general use
internet, with unlimited bulk traffic for $y.yy".  Of course, the MSOs
wouldn't say that the first category excludes bulk traffic, or mention caps
or upstream limitations or P2P control because that would be bad for
marketing. 

 

Frank

 

From: Dorn Hetzel [mailto:dhetzel@gmail.com] 
Sent: Wednesday, October 24, 2007 8:12 AM
To: Joe Greco
Cc: frnkblk@iname.com; nanog@merit.edu
Subject: Re: BitTorrent swarms have a deadly bite on broadband nets

 

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.  

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.

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. 

Maybe the default should be high priority so that customers who do nothing
but are light users get the best service.

low priority upstream traffic gets dropped in favor of high priority, but
users decide what's important to them. 

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.

This seems like it would be reasonable and fair and p2p wouldn't have to be
singled out. 

Any thoughts?

On 10/22/07, Joe Greco <jgreco@ns.sol.net> wrote:


> I wonder how quickly applications and network gear would implement QoS
> support if the major ISPs offered their subscribers two queues: a default
> queue, which handled regular internet traffic but squashed P2P, and then a

> separate queue that allowed P2P to flow uninhibited for an extra $5/month,
> but then ISPs could purchase cheaper bandwidth for that.
>
> But perhaps at the end of the day Andrew O. is right and it's best off to 
> have a single queue and throw more bandwidth at the problem.

A system that wasn't P2P-centric could be interesting, though making it
P2P-centric would be easier, I'm sure.  ;-)

The idea that Internet data flows would ever stop probably doesn't work 
out well for the average user.

What about a system that would /guarantee/ a low amount of data on a low
priority queue, but would also provide access to whatever excess capacity
was currently available (if any)? 

We've already seen service providers such as Virgin UK implementing things
which essentially try to do this, where during primetime they'll limit the
largest consumers of bandwidth for 4 hours.  The method is completely 
different, but the end result looks somewhat similar.  The recent
discussion of AU service providers also talks about providing a baseline
service once you've exceeded your quota, which is a simplified version of 
this.

Would it be better for networks to focus on separating data classes and
providing a product that's actually capable of quality-of-service style
attributes?

Would it be beneficial to be able to do this on an end-to-end basis (which 
implies being able to QoS across ASN's)?

The real problem with the "throw more bandwidth" solution is that at some
point, you simply cannot do it, since the available capacity on your last
mile simply isn't sufficient for the numbers you're selling, even if you 
are able to buy cheaper upstream bandwidth for it.

Perhaps that's just an argument to fix the last mile.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN) 
With 24 million small businesses in the US alone, that's way too many
apples.

 


------=_NextPart_000_00AC_01C8161E.668B3C10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.gmailquote
	{mso-style-name:gmail_quote;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Tahoma","sans-serif";
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'>The key thing is that it can&#8217;t be too complicated for =
the
subscriber.&nbsp; What you&#8217;ve described is already too difficult =
for the
masses to consume.&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'>The scavenger class, as has been described in other =
postings, is probably
the simplest way to implement things.&nbsp; Let the application =
developers take
care of the traffic marking and expose priorities in the GUI, and the =
marketing
from the MSO needs to be &#8220;$xx.xx per month for general use =
internet, with
unlimited bulk traffic for $y.yy&#8221;.&nbsp; Of course, the MSOs =
wouldn&#8217;t
say that the first category excludes bulk traffic, or mention caps or =
upstream
limitations or P2P control because that would be bad for marketing. =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'>Frank<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:blue'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dorn =
Hetzel
[mailto:dhetzel@gmail.com] <br>
<b>Sent:</b> Wednesday, October 24, 2007 8:12 AM<br>
<b>To:</b> Joe Greco<br>
<b>Cc:</b> frnkblk@iname.com; nanog@merit.edu<br>
<b>Subject:</b> Re: BitTorrent swarms have a deadly bite on broadband =
nets<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>How about a system =
where I tell
my customers that for a given plan X at price Y they get U bytes of =
&quot;high
priority&quot; upload per month (or day or whatever) and after that all =
their
traffic is low priority until the next cycle starts.&nbsp; <br>
<br>
Now here's the fun part.&nbsp; 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.&nbsp; 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?<o:p></o:p></p>

<div>

<p class=3DMsoNormal><span class=3Dgmailquote>On 10/22/07, <b>Joe =
Greco</b> &lt;<a
href=3D"mailto:jgreco@ns.sol.net">jgreco@ns.sol.net</a>&gt; =
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal><br>
&gt; I wonder how quickly applications and network gear would implement =
QoS<br>
&gt; support if the major ISPs offered their subscribers two queues: a =
default<br>
&gt; queue, which handled regular internet traffic but squashed P2P, and =
then a
<br>
&gt; separate queue that allowed P2P to flow uninhibited for an extra =
$5/month,<br>
&gt; but then ISPs could purchase cheaper bandwidth for that.<br>
&gt;<br>
&gt; But perhaps at the end of the day Andrew O. is right and it's best =
off to <br>
&gt; 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.&nbsp;&nbsp;;-)<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.&nbsp;&nbsp;The method is =
completely
<br>
different, but the end result looks somewhat similar.&nbsp;&nbsp;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 &quot;throw more bandwidth&quot; 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=3D"http://sol.net">sol.net</a> Network Services - =
Milwaukee,
WI - <a href=3D"http://www.sol.net">http://www.sol.net</a><br>
&quot;We call it the 'one bite at the apple' rule. Give me one chance =
[and] then
I<br>
won't contact you again.&quot; - 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.<o:p></o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_00AC_01C8161E.668B3C10--


home help back first fref pref prev next nref lref last post