Date: Thu, 12 Jun 2008 07:31:50 -0400 (EDT)
From: Laird Popkin <laird@pando.com>
To: p2pi@ietf.org
Message-ID: <1669260528.386321213270310916.JavaMail.root@dkny.pando.com>
In-Reply-To: <1506959200.386261213269833072.JavaMail.root@dkny.pando.com>
MIME-Version: 1.0
Subject: [p2pi] We don't need to treat users fairly,
 we need to maximize their happiness!
Precedence: list
Content-Type: multipart/mixed; boundary="===============0140513747=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

--===============0140513747==
Content-Type: multipart/alternative; 
 boundary="----=_Part_15684_594244554.1213270310916"

------=_Part_15684_594244554.1213270310916
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The term 'fairness' is (IMO) distracting us from the real goals, since that=
 word has emotional=C2=A0 implications =C2=A0(e.g. "unfairness"). And a dis=
cussion about fairness assumes that our goal is equal resource allocation i=
n the context of a 'zero sum game'. I think that there equal allocation of =
resources isn't the best answer for users (e.g. a VOIP call and a PodCast a=
ren't equal value bits), and there are certainly some cases where we're not=
 in a zero sum game (i.e. being smarter can get much more performance out o=
f the same physical resources). And, at least as relates to the p2p issues =
we're discussing, I don't know that fairness is even particularly important=
.=20


I think what we're ultimately trying to achieve is to maximize user happine=
ss when on a constrained network. This is different from "fairness" in that=
 there are some pretty obvious cases where being "fair" does not maximize u=
ser satisfaction. That's not to say that fairness is bad - fairness is the =
best the network can do if there's no visibility into the actual value of t=
he data, or ability to influence application-level decisions. But fairness =
isn't really our goal. Maximized user satisfaction is our goal.=20


User satisfaction is, of course, too broad to use an an engineering goal di=
rectly. But there are many specific ideas that all address, in one way or a=
nother, the issue of maximizing user satisfaction in a resource limited env=
ironment:=20
- Peer selection based on network topology (e.g. P4P) allows p2p to consume=
 fewer resources and improving performance. Faster downloads make users hap=
py.=20
- Knowing which streams are congested (e.g. Re-ECN) allows apps to select b=
etween data sources to shift traffic away from congested areas. This improv=
es performance for all concerned (users and their neighbors), making users =
happy.=20
- Marking background transfer data as "scavenger class" could allow congest=
ed links to focus resources on the most time critical data. This makes the =
users with time sensitive transfers happy, and hopefully doesn't make the u=
sers doing background transfers unhappy.=20
- ISPs exposing user quota status could allow applications to avoid trigger=
ing surcharges, or hitting caps, allow users to make informed decisions, et=
c. This makes the users happy.=20


etc.=20

-=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks=20
=C2=A0=C2=A0mobile:=C2=A0646/465-0570=20

----- Original Message -----=20
From: "Richard Bennett" <richard@bennett.com>=20
To: "Daniel Weitzner" <djweitzner@csail.mit.edu>=20
Cc: p2pi@ietf.org=20
Sent: Wednesday, June 11, 2008 9:51:37 PM (GMT-0500) America/New_York=20
Subject: Re: [p2pi] One more proposed definition of fairness...=20

Comments in-line:=20

Daniel Weitzner wrote:=20

Reflecting on the thread that followed Nick's original proposal =20
(quoted below)....

I'd suggest that there are actually two kinds of fairness under =20
discussion:

1. fairness between ISPs and their customers: you get the bandwidth =20
and latency you pay for where those values are averaged over some =20
stated period This isn't the scope of "fairness" as it's generally understo=
od in networking standards, at least not the ones that I've worked on. I wo=
uld suggest that "disclosure" or something along that line is the more rele=
vant term. When engineers specify "fairness" mechanism, they generally have=
 to do with your item number 2 below, an aspect of the multiple-access prob=
lem.=20


2. fairness amongst network users: there are network mechanisms that =20
guard against some traffic (perhaps generated by the hypothesized 5%) =20
consistently degrading the traffic of others. That is, even though I =20
may be receiving the promised average bandwidth as measured over a =20
long period of time, the instantaneous performance is poor enough that =20
I feel it.

 From the comments I've read I'll go out on a limb and suggest that no =20
one really disagrees with the importance of achieving either notion.

I'll go further on a said limb and suggest that the IETF concentrate =20
on mechanisms for enabling user-to-user fairness (#2) because it seems =20
like a tractable engineering problem. User-to-user fairness is =20
necessary but not sufficient to achieving user-to-ISP fairness (#1). =20
It is the case that even with user-to-user fairness, ISPs may have to =20
re-think their network provisioning in order to live up to their =20
contractual and/or marketing promises made to users. That, however, is =20
a business and regulatory problem. I do agree that it is important to =20
have verifiable service metrics, but am not sure that this is the =20
right place to sort those out. The suggestion for a TANA BOF in Dublin ment=
ions the importance of metrics, to wit, relevant text highlighted:=20

(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 i=
nterconnection information - metrics - it seems like a small step to aggreg=
ate and export this for the purpose of service verification. But perhaps se=
rvice verification is simply something that can be understood as an "applic=
ation."=20

In any event, "fairness" is only one of the issues in this work area, takin=
g its place alongside congestion, optimization, and others.=20

RB=20

--=20
Richard Bennett=20
_______________________________________________ p2pi mailing list p2pi@ietf=
.org https://www.ietf.org/mailman/listinfo/p2pi
------=_Part_15684_594244554.1213270310916
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style><style type=3D=
'text/css'>body { font-family: 'Times New Roman'; font-size: 12pt; color: #=
000000}</style></head><body>The term 'fairness' is (IMO) distracting us fro=
m the real goals, since that word has emotional=C2=A0implications=C2=A0(e.g=
. "unfairness"). And a discussion about fairness assumes that our goal is e=
qual resource allocation in the context of a 'zero sum game'. I think that =
there equal allocation of resources isn't the best answer for users (e.g. a=
 VOIP call and a PodCast aren't equal value bits), and there are certainly =
some cases where we're not in a zero sum game (i.e. being smarter can get m=
uch more performance out of the same physical resources). And, at least as =
relates to the p2p issues we're discussing, I don't know that fairness is e=
ven particularly important.<div><br></div><div>I think what we're ultimatel=
y trying to achieve is to maximize user happiness when on a constrained net=
work. This is different from "fairness" in that there are some pretty obvio=
us cases where being "fair" does not maximize user satisfaction. That's not=
 to say that fairness is bad - fairness is the best the network can do if t=
here's no visibility into the actual value of the data, or ability to influ=
ence application-level decisions. But fairness isn't really our goal. Maxim=
ized user satisfaction is our goal.</div><div><br></div><div>User satisfact=
ion is, of course, too broad to use an an engineering goal directly. But th=
ere are many specific ideas that all address, in one way or another, the is=
sue of maximizing user satisfaction in a resource limited environment:</div=
><div>- Peer selection based on network topology (e.g. P4P) allows p2p to c=
onsume fewer resources and improving performance. Faster downloads make use=
rs happy.</div><div>- Knowing which streams are congested (e.g. Re-ECN) all=
ows apps to select between data sources to shift traffic away from congeste=
d areas. This improves performance for all concerned (users and their neigh=
bors), making users happy.</div><div>- Marking background transfer data as =
"scavenger class" could allow congested links to focus resources on the mos=
t time critical data. This makes the users with time sensitive transfers ha=
ppy, and hopefully doesn't make the users doing background transfers unhapp=
y.</div><div>- ISPs exposing user quota status could allow applications to =
avoid triggering surcharges, or hitting caps, allow users to make informed =
decisions, etc. This makes the users happy.</div><div><br></div><div>etc.</=
div><div><br>-=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks<b=
r>=C2=A0=C2=A0mobile:=C2=A0646/465-0570<br><br>----- Original Message -----=
<br>From: "Richard Bennett" &lt;richard@bennett.com><br>To: "Daniel Weitzne=
r" &lt;djweitzner@csail.mit.edu><br>Cc: p2pi@ietf.org<br>Sent: Wednesday, J=
une 11, 2008 9:51:37 PM (GMT-0500) America/New_York<br>Subject: Re: [p2pi] =
One more proposed definition of fairness...<br><br>

Comments in-line:<br>
<br>
Daniel Weitzner wrote:
<blockquote cite=3D"mid:39ED814C-BEA0-4BDF-B7B1-9BE0B480991E@csail.mit.edu"=
>
  <pre>Reflecting on the thread that followed Nick's original proposal =20
(quoted below)....

I'd suggest that there are actually two kinds of fairness under =20
discussion:

1. fairness between ISPs and their customers: you get the bandwidth =20
and latency you pay for where those values are averaged over some =20
stated period</pre>
</blockquote>
<font color=3D"#3333ff">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.</font><br>
<blockquote cite=3D"mid:39ED814C-BEA0-4BDF-B7B1-9BE0B480991E@csail.mit.edu"=
>
  <pre>2. fairness amongst network users: there are network mechanisms that=
 =20
guard against some traffic (perhaps generated by the hypothesized 5%) =20
consistently degrading the traffic of others. That is, even though I =20
may be receiving the promised average bandwidth as measured over a =20
long period of time, the instantaneous performance is poor enough that =20
I feel it.

 From the comments I've read I'll go out on a limb and suggest that no =20
one really disagrees with the importance of achieving either notion.

I'll go further on a said limb and suggest that the IETF concentrate =20
on mechanisms for enabling user-to-user fairness (#2) because it seems =20
like a tractable engineering problem. User-to-user fairness is =20
necessary but not sufficient to achieving user-to-ISP fairness (#1). =20
It is the case that even with user-to-user fairness, ISPs may have to =20
re-think their network provisioning in order to live up to their =20
contractual and/or marketing promises made to users. That, however, is =20
a business and regulatory problem. I do agree that it is important to =20
have verifiable service metrics, but am not sure that this is the =20
right place to sort those out.
  </pre>
</blockquote>
<font color=3D"#3333ff">The suggestion for a TANA BOF in Dublin mentions
the importance of metrics, to wit, relevant text highlighted:<br>
<br>
</font>
<pre style=3D"margin: 0em;"><font color=3D"#3333ff">(3) A mechanism that le=
ts 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 <b>what kinds of dynamic interconnection
    information is useful to applications</b>, 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.

</font></pre>
<font color=3D"#3333ff">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."<br>
<br>
In any event, "fairness" is only one of the issues in this work area,
taking its place alongside congestion, optimization, and others.<br>
<br>
RB</font><br>
<br>
<pre class=3D"moz-signature">--=20
Richard Bennett
</pre>


<br>_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
</div></body></html>
------=_Part_15684_594244554.1213270310916--

--===============0140513747==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

--===============0140513747==--