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

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

On Jun 8, 2008, at 10:41 PM, Joe Touch wrote:
> ...
>> 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,...
>
> That's the point, however, where things stop when someone uses  
> encrypted transport layers.

As long as the end point address is NOT encrypted, it doesn't matter.

> ...
>> 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).
>
> A key question is whether it's worth the state it will take to get  
> right. An endpoint might open a few thousand flows just to help  
> overload your system ;-)

a)  A few thousand is nothing.  You have to be talking tens of  
thousands to start with before I should start caring.


b)  There are some really nice structures that work for cheating.  EG,  
a 256k entry flow cache is probably sufficient, if you have a LRU  
policy, for even large networks since you are measuring short duration  
properties (to determine loss).

Looking at Berkeley's access network, I think a 256k entry or 512k  
entry cache would be sufficient to effectively never have evictions of  
flows in less than 2 seconds, and you could easily structure things so  
that if you lose a little precision through cache evictions, it  
doesn't matter.

Yes, tracking EXACTLY is very problematic.  But tracking approximately  
is far far easier.


c)  If a single host or small group of hosts starts doing behavior  
designed to disrupt the flow cache deliberately (eg, >10k ACTIVE TCP  
flows), I think the ISPs device can start doing some rate limiting on  
flow creation as well, as there is a strong case that such is  
suspicious behavior.


d)  "State is cheap, its ACCESSING state is expensive" if you look at  
modern memory technology.  DRAM is slow.  DRAM has awful latency.

But assuming a reasonable median packet size of about ~200B, you can  
still access one or maby two locations in DRAM even on a 10 GigE device.

Thus if you can have your algorithm so that it may have 1 GB of  
memory, but only needs to access one location (say a cache line) for a  
read/update, you can probably manage things.


>
>
>> 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.
>
> Sure - the local ISP can prevent that. You can't prevent someone  
> accessing multiple ISPs (cable, DSL, etc.), but presumably you don't  
> care about that?
>

Yeah, why should the ISP care?  Its because common congestion pretty  
much only occurs within the ISP, so it is the ISP's problem to  
mitigate, and in the ISP's interest to mitigate.

Someone who's using multiple ISPs to transfer more bits is paying for  
those extra bits, and it doesn't really matter.


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