Re: [p2pi] One more proposed definition of fairness...

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

On Jun 8, 2008, at 10:39 AM, Joe Touch wrote:
> Nicholas Weaver wrote:
>> (Buried in a previous mail, but I'd like comments on this separately)
>> How does the following sound as one possible ideal goal for user-  
>> fairness:
>> "Mechanisms to enable the network to enforce traffic such that, in  
>> the  presence of congestion, a user's congestion control response  
>> becomes  equivalent to aggregating all traffic from that user into  
>> a single TCP  stream."
>
> See the Congestion Manager or RFC2140 ;-)
>
> This is easy to do at the end system, but, AFAICT, impossible to  
> accomplish anywhere else (users will just grab multiple IP  
> addresses, e.g.) - or worse, involves violating TCP (or,  
> equivalently, won't work on encrypted/authenticated streams).


I'm a security person.  I have to assume the end systems don't behave  
right.  But I actually don't think it is impossible to enforce in the  
network for the local users' ISP.


EG, the ISP can at a single bidirectional point in the network  
(admittedly keeping lots of state, but...) for a large group of users  
infer the congestion on each TCP flow, and correlate across multiple  
flows on multiple users to see

a)  There is common congestion affecting a large group of flows

b)  What the available bottleneck bandwidth for the common point of  
congestion

and then

c)  ECN mark/drop packets from the user's flows at the common point of  
congestion, so that when a user has multiple TCP flows they experience  
the same throughput they would if they just had one TCP flow.

Yes, this is a LOT of engineering work to get right [1], but I believe  
it is doable, and could accomplish the stated definition of fairness  
(or something very close to it).


Furthermore, you can resist the attacks you mentioned.  Because the  
ISP can prevent the user from minting new IP addresses (as they  
control the point of attachment), this prevents address forging.

And because the ISP is forcing the flows to drop packets remote of the  
point of congestion to maintain the target flow, if the end host is  
doing ANY congestion control at all, it will be forced to conform to  
the allocated fair share. [2]


It was also pointed out to me that http://www.anagran.com/ actually  
claims to be targeting this ability, or something similar, managing  
congestion that is remote from the point of management, although their  
web site literature is pretty shy on information on how they are doing  
it.




[1] note, however, it doesn't have to be perfect: sampling and other  
approximations can allow you to bound state at the cost of complete  
accuracy.  And it only has to work at 1 Gbps to be deployable in many  
networks today (well within the range of a commodity PC) and there is  
enough available parallelism that you could probably implement at 10  
Gbps on a Tilera-based system or other highly parallel programmable  
system.

[2] And even completely unresponsive flows can be shaped as long as  
the actual bottleneck is downstream of the point of management and, if  
upstream, this could easily be considered an attack on the network and  
an ACL block would probably be appropriate.

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