Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

On Jun 2, 2008, at 9:06 AM, Laird Popkin wrote:
>
>
> - Allow applications to tag some traffic as 'not time sensitive' so  
> that ISPs can manage bulk traffic as lower priority than time- 
> sensitive traffic. There would need to be a benefit to the  
> application for doing so, such as excluding such traffic from ISP  
> capacity limits.

I actually think the opposite ("tag as priority") is better, because  
its easy to do "tag & cap" and the incentives match up better.

Here's why...


There is no benefit to saying "I'm worse than best effort", because  
any application who's worse-than-best effort can always use a  
friendlier than TCP congestion control ( http://www.icir.org/floyd/tcp_small.html 
  has a list), have the same effect on the network, and suddenly go  
unnoticed in moments of congestion without requiring network support  
for QoS to be enabled.

Given the problems users are experiencing with BitTorrent just on  
their own network ( http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx 
  , http://tech.slashdot.org/article.pl?sid=08/05/24/1859218 ), there  
actually seems to be some incentive in place for the bulk-data P2P  
developers to use one of the existing off-the-shelf solutions for  
friendlier-than-TCP behavior (note, this is something I was WRONG on  
earlier, as I thought there was no incentive), and if they don't have  
incentive to use friendlier-than-TCP, why would they have incentive to  
mark as 'not time sensitive', as they would accomplish the same  
thing.  [1]



However there is a benefit to saying "I'm better than best effort",  
for applications like VoIP or online games, or even the non-image  
portions of your HTTP requests.  ISPs can spend a lot of effort using  
packet analysis to determine these flows, or just rely on the  
endpoints to get it right.


There is no benefit to cheating, IF the network enforces a cap on the  
number of (packets/bytes) sent with priority per (ms/sec/minute/hour),  
as the measurement is relatively easy to enforce (1 memory lookup/ 
update per packet, and because its only high-volume users which have  
an incentive to cheat, you can easily use a small LRU cache for  
addresses).



[1] It might be the role of the OS to implement some of this.  EG,  
coupling AIMD across all flows of an application, combined with some  
more detailed RTT-based congestion control a'la TCP Vegas, again  
correlating across multiple flows)

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi