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

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

On Jun 9, 2008, at 6:19 AM, Joe Touch wrote:

>
>
> Nicholas Weaver wrote:
>> 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.
>
> How might I infer the congestion on each TCP flow when I can't see  
> TCP connections, e.g.?
>

As long as there is SOME fraction that is TCP, I can still infer the  
common congestion, using it as a canary.

And since such a device is  part of the ISP's infrastructure, it could  
also get the ISP's internal routing table, so you can use some TCP  
flows to sample where common congestion occurs, and routing  
information to determine what is affected by common congestion.


It also doesn't matter if ECN is enabled, at least for the upstream  
congestion.  ECN signals congestion in the IP layer, which means that  
even for encrypted tunnels, the ECN data is available to make  
decisions on detecting congestion.

Re-ECN would allow you to see both upstream and downstream congestion.


>>> ...
>>>> 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 ;-)
> ...
>
> ...
>> 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.
>
> How can you infer that >10K flows from a host is deliberate  
> disruption? If I buy an Internet connection from an ISP, I get as  
> many flows as I can connect to.
>
> Or have you decided that "the Internet" is now only as many flows as  
> you can track efficiently? (see below)

Actually, many users have a practical limit of <8K flows due to their  
NAT boxes anyway (and some have <1K flows).

Furthermore, depending on how you cache things, since it is only  
MONITORING that needs to be done per-flow (policing needs to be per- 
user anyway), if someone tries to blow out the flow-cache, well, so  
what?

Track some subset of their flows, don't use their flows to evict other  
flows (but if there is cache space, you still cache them), and be  
happy: you can always subsample and still get the information you  
need, albeit with a bit of degradation in accuracy.

Thats the other beauty of just monitoring flows (but acting on users),  
you can easily tolerate not being able to monitor all flows.


>>>> 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.
>
> Maybe I'm missing something, but if I have one ISP, I paid for THOSE  
> bits too. How I use them is up to me, not the ISP.

I don't see what our disagreement is.  Users paying for multiple  
accounts get more bandwidth, and as ISP A doesnt' see the packets  
going through ISP-B, it doesn't matter to A what they are doing  
elsewhere.


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