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

Comments in-line:

Daniel Weitzner wrote:
> Reflecting on the thread that followed Nick's original proposal  
> (quoted below)....
>
> I'd suggest that there are actually two kinds of fairness under  
> discussion:
>
> 1. fairness between ISPs and their customers: you get the bandwidth  
> and latency you pay for where those values are averaged over some  
> stated period
This isn't the scope of "fairness" as it's generally understood in 
networking standards, at least not the ones that I've worked on. I would 
suggest that "disclosure" or something along that line is the more 
relevant term. When engineers specify "fairness" mechanism, they 
generally have to do with your item number 2 below, an aspect of the 
multiple-access problem.
> 2. fairness amongst network users: there are network mechanisms that  
> guard against some traffic (perhaps generated by the hypothesized 5%)  
> consistently degrading the traffic of others. That is, even though I  
> may be receiving the promised average bandwidth as measured over a  
> long period of time, the instantaneous performance is poor enough that  
> I feel it.
>
>  From the comments I've read I'll go out on a limb and suggest that no  
> one really disagrees with the importance of achieving either notion.
>
> I'll go further on a said limb and suggest that the IETF concentrate  
> on mechanisms for enabling user-to-user fairness (#2) because it seems  
> like a tractable engineering problem. User-to-user fairness is  
> necessary but not sufficient to achieving user-to-ISP fairness (#1).  
> It is the case that even with user-to-user fairness, ISPs may have to  
> re-think their network provisioning in order to live up to their  
> contractual and/or marketing promises made to users. That, however, is  
> a business and regulatory problem. I do agree that it is important to  
> have verifiable service metrics, but am not sure that this is the  
> right place to sort those out.
>   
The suggestion for a TANA BOF in Dublin mentions the importance of 
metrics, to wit, relevant text highlighted:

(3) A mechanism that lets an application that can
    transfer data from or to several potential peers (i.e.,
    servers, caches, end systems) select a subset of peers
    for efficient transmission in a way that is aligned with
    the dynamic interconnection structure of the network
    operators that provide connectivity to those peers.
    Application designers, network equipment vendors and
    network operators will need to collaborate on this work
    item to define *what kinds of dynamic interconnection
    information is useful to applications*, how to obtain it,
    and how to provide it to applications, resulting in a
    generic mechanism that is broadly applicable to many
    current and future applications.

Given that applications need dynamic interconnection information - 
metrics - it seems like a small step to aggregate and export this for 
the purpose of service verification. But perhaps service verification is 
simply something that can be understood as an "application."

In any event, "fairness" is only one of the issues in this work area, 
taking its place alongside congestion, optimization, and others.

RB

-- 
Richard Bennett