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

From: Nicholas Weaver <[email-masked]>
Date: Sun, 8 Jun 2008 09:19:15 -0700

(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."

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Joe Touch <[email-masked]>
Date: Sun, 08 Jun 2008 10:39:36 -0700

> equivalent to aggregating all traffic from that user into a single TCP  

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).

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 8 Jun 2008 12:18:50 -0700

On Jun 8, 2008, at 10:39 AM, Joe Touch wrote:
>> "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."
>
> 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.

---

From: "Stas Khirman" <[email-masked]>
Date: Sun, 8 Jun 2008 16:33:15 -0700

> web site literature is pretty shy on information on how they are doing
[Stas Khirman] 
They probably refer to implementation of the TIA 1039 / ITU Y.2121
(Y.flowreq) recommendations

http://www.anagran.com/technology_enhanced_flow_rate_signaling.php 

The main idea is to negotiate capacity reservation on the first few packets
of the flow ( SYN and SYN-ACK for example) using "in-band" signaling. Flow
reservation request/response information is "attached" to the original TCP
packet as an TCP option .  

IMHO, the main Y.flowreq challenge is to how originator of Y.flowreq request
decides to classify a new arbitrary flow. It hard to believe that many end
nodes will have "modified TCP/IP stack" installed anytime soon. Even if
deployed, it will need a modification of networking applications ( or
development new ones) to directly control FLOWREQ API.  Alternative, is to
use some kind heuristically (or DPI) flow classification, but it not always
work well, especially if application ( like p2p) try to hide its protocol.

P.S. I have no idea if Y.flowreq had been reviewed by IETF and will
appreciate any input on this topic.

---

From: Joe Touch <[email-masked]>
Date: Sun, 08 Jun 2008 22:41:57 -0700

Nicholas Weaver wrote:
>>> becomes  equivalent to aggregating all traffic from that user into a 
>>> single TCP  stream."
>>
...
> infer the congestion on each TCP flow,...

That's the point, however, where things stop when someone uses encrypted 
transport layers.

...
> 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 ;-)

> 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?

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 9 Jun 2008 11:25:21 +0200

> appreciate any input on this topic.

It has; the transport area has exchanged a number of liaison  
statements with the ITU-T on this over the last few years. The latest  
one, FYI, is at https://datatracker.ietf.org/liaison/447/.

The executive summary is that Y.flowreq proposes to redefine a number  
of core Internet protocols in a way that isn't clearly understood at a  
technical level, and the interactions of those changes with the rest  
of the Internet protocol suite are even more unclear at this point.  
We've cautioned the ITU-T that a realization of Y.flowreq requires  
changes to protocols that aren't under their control, and that any  
such work will hence need to happen in the IETF.

Lars

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 05:41:30 -0700

On Jun 8, 2008, at 10:41 PM, Joe Touch wrote:
>> (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).
>
> 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.

> accessing multiple ISPs (cable, DSL, etc.), but presumably you don't  

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.

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2008 06:19:36 -0700

> 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.?

...

...
> 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)

> much only occurs within the ISP, so it is the ISP's problem to mitigate, 
> and in the ISP's interest to mitigate.
> 

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.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 07:43:31 -0700

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

> 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.

>>>> believe it is doable, and could accomplish the stated definition  
>>>> of fairness (or something very close to it).
>>>
>> 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.
>>>
>>> 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.
>

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.

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2008 07:58:22 -0700

Nicholas Weaver wrote:
...
> 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.

We agree on that. We agree that if I pay two ISPs for BW, I get to use 
both. Do you agree that if I pay one ISP for BW, I get to use it - all 
of it? (i.e., if this is about ISP internal congestion, then the ISP is 
at fault for underprovisioning, not the user)

I get the impression that if an ISP has upstream congestion, you think 
it gets to limit the number of flows I send; I think that my packets can 
get dropped due to congestion, but it's not useful for the ISP to have a 
different notion of 'fairness' than the endpoint.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 08:37:06 -0700

On Jun 9, 2008, at 7:58 AM, Joe Touch wrote:
>>>>
>>>
>>> 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.
> We agree on that. We agree that if I pay two ISPs for BW, I get to  
> use both. Do you agree that if I pay one ISP for BW, I get to use it  
> - all of it? (i.e., if this is about ISP internal congestion, then  
> the ISP is at fault for underprovisioning, not the user)
>
> I get the impression that if an ISP has upstream congestion, you  
> think it gets to limit the number of flows I send; I think that my  
> packets can get dropped due to congestion, but it's not useful for  
> the ISP to have a different notion of 'fairness' than the endpoint.

Actually, I disagree here, for the following reason:

a:  The endpoints have a proven in practice bad notion of fairness:   
They have TCP flow fairness (which can and is abused by some users,  
who eg, transfer on many torrents simultaneously), or (with crap like  
Joost) no fairness at all.  Why should someone who's playing by the  
"rules" (a few TCP streams) have to compete against users who aren't  
(many TCP streams or UDP based volume protocols without congestion  
control)?

Flow rate fairness is not user fairness.

b:  More importantly, in the flat rate pricing world, if a fairness  
mechanism which allocates traffic between users is such that 90% of  
the users DON'T experience significant long-term congestion, the ISP  
is actually properly provisioned, not underprovisioned.

It does not make economic sense to up capacity to serve just 5-10%  
heavy-tail of the users, as those 5-10% of the users aren't paying any  
more than the 90%.

If this is the case, ISPs need to either prevent the heavy-tailed  
users from affecting the rest (fairness, app-discrimination, usage  
caps) or charge the heavy users more (usage-based pricing) to justify  
the cost of an expansion which only benefits these users.

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2008 09:20:56 -0700

Nicholas Weaver wrote:
>> of it? (i.e., if this is about ISP internal congestion, then the ISP 
>> is at fault for underprovisioning, not the user)
>>
>> it gets to limit the number of flows I send; I think that my packets 
>> can get dropped due to congestion, but it's not useful for the ISP to 
>> have a different notion of 'fairness' than the endpoint.
> 
> They have TCP flow fairness (which can and is abused by some users, who 
> eg, transfer on many torrents simultaneously), or (with crap like Joost) 
> no fairness at all.  Why should someone who's playing by the "rules" (a 
> few TCP streams) have to compete against users who aren't (many TCP 
> streams or UDP based volume protocols without congestion control)?
> 

Right. But what is enforced depends on what the user paid for...

> mechanism which allocates traffic between users is such that 90% of the 
> users DON'T experience significant long-term congestion, the ISP is 
> actually properly provisioned, not underprovisioned.
> 

I don't care what "economic sense" it made for the ISP. If it sold me X 
Mbps, it had better provide that. If there's upstream congestion, that's 
another issue, of course. But if not, if you sell me X Mbps, I had 
better get it.

> If this is the case, ISPs need to either prevent the heavy-tailed users 
> from affecting the rest (fairness, app-discrimination, usage caps) or 
> charge the heavy users more (usage-based pricing) to justify the cost of 
> an expansion which only benefits these users.

AND define what they're selling better. Don't sell me a gallon of gas 
which is a gallon UNLESS there's a run on gasoline. I don't care about 
*your* economic implications of heavy-tails on your provisioning model. 
I care about getting what I paid for.

Once I pay for X Mbps, you can throttle ALL my stuff, but not just TCP, 
and not per-flow or anything else. If you do, you're not selling me 
Internet access, you're selling me a single TCP connection or somesuch, 
and nobody would buy that.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 09:50:00 -0700

On Jun 9, 2008, at 9:20 AM, Joe Touch wrote:
>> a:  The endpoints have a proven in practice bad notion of  
>> fairness:  They have TCP flow fairness (which can and is abused by  
>> some users, who eg, transfer on many torrents simultaneously), or  
>> (with crap like Joost) no fairness at all.  Why should someone  
>> who's playing by the "rules" (a few TCP streams) have to compete  
>> against users who aren't (many TCP streams or UDP based volume  
>> protocols without congestion control)?
>> the users DON'T experience significant long-term congestion, the  
>> ISP is actually properly provisioned, not underprovisioned.
>> heavy-tail of the users, as those 5-10% of the users aren't paying  
>> any more than the 90%.
>
> I don't care what "economic sense" it made for the ISP. If it sold  
> me X Mbps, it had better provide that. If there's upstream  
> congestion, that's another issue, of course. But if not, if you sell  
> me X Mbps, I had better get it.

Fairness only needs to be enforced when there is congestion.  So  
what's the problem?

No congestion, you get your X Mbps.  Your bits flow and you are happy.

With congestion, you get a defined fair allocation, averaged out over  
say, 1 second to 1 hour.

>> caps) or charge the heavy users more (usage-based pricing) to  
>> justify the cost of an expansion which only benefits these users.
>
> AND define what they're selling better. Don't sell me a gallon of  
> gas which is a gallon UNLESS there's a run on gasoline. I don't care  
> about *your* economic implications of heavy-tails on your  
> provisioning model. I care about getting what I paid for.
>
> Once I pay for X Mbps, you can throttle ALL my stuff, but not just  
> TCP, and not per-flow or anything else. If you do, you're not  
> selling me Internet access, you're selling me a single TCP  
> connection or somesuch, and nobody would buy that.

If you want X no matter what anyone else is doing, you buy business  
grade service with an SLA and lose statistical multiplexing.  Just be  
prepared for sticker shock.

There is a reason such a product is not sold to consumers: statistical  
multiplexing is a huge win in cost-savings, but it means you can only  
guarentee a number much MUCH smaller than X.  EG, Lariat is very open  
about their pricing and does provide such guarentees.  Going from a  
guarenteed 256 Kbps to a guarenteed 512 Kbps doubles your cost from  
$40 to $80 [1]!

If, instead, you REQUIRE that an ISP allocate a 16 Mbps channel for  
your exclusive usage, you would see the bill jump by 5x-10x easily.

So yes, you should care about your ISP's cost and business model.   
Even if they have a 50% profit margin, any change which would up their  
costs by a factor of 10, and they only passed on the actual costs,  
would see your bill jump by 5x!

Also, with all the pushback against fairness, I see way the ISPs want  
to go to bandwidth caps and bill-released bandwidth caps instead:  
Rather than trying to make the network work with the 5%ers, just cut  
off the 5%ers!

If it happens to disrupt video-on-demand services (which it will,  
bigtime), consider it a bonus.

[1] And its not like thats pure profit either.  Brett Glass is open  
about his own prices, and claims that it costs him $100/Mbps-month, so  
the MINIMUM price difference for the differentiation in service has to  
be at least $25.

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2008 10:23:16 -0700

Nicholas Weaver wrote:
...
...
> prepared for sticker shock.

That was the telco's argument in the 1980s when modems shot 50+ years of 
erlang analysis out the window; in the end, they *reprovisioned* to 
accommodate the reality of what they were selling - and the prices 
didn't change all that much.

IMO, ISPs are headed down this path too. I don't care much that the 
current realities don't match their outdated provisioning models, any 
more than I care that the cable co's initially mis-guessed the ratio of 
uplink to downlink BW.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 10:36:08 -0700

On Jun 9, 2008, at 10:23 AM, Joe Touch wrote:
> current realities don't match their outdated provisioning models,  
> any more than I care that the cable co's initially mis-guessed the  
> ratio of uplink to downlink BW.

And if that is the case, a fairness discipline doesn't work, and will  
tell you empirically that you actually are underprovisioned for the  
majority of your users, not just the 5% heavy-tail.

---

From: "Stas Khirman" <[email-masked]>
Date: Mon, 9 Jun 2008 10:46:44 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> 
[Stas Khirman] 

As matter of fact, ANY flat rate resource sharing system will have 5% of
"heavy" users consuming 50% of shared resource - it is just a special case
of famous 20/80 Pareto observation. It is observed in any kinds of
flat-rate/free services - from broadband ISP, dial-up , local phone service,
NetFlix down to local library or "all-you-can-eat" buffet.

Serving those 5% of "heavy users" is a part of economical sense of flat-rate
- their overuse of shared resource is well sponsored by the monthly fee of
the 95% "light users". And certainly, it is not "fair" - flat-rate can't be
fair on any level as charges are not reflecting your specific use of the
service. BTW, I do not see ISP are suggesting to give back some discounts to
80% of "light users" who use less then 20% of total resources - it will
certainly make no economical sense to ISP despite obvious fairness . 

As long as service providers use flat-rate pricing model they have to plan
servicing 5% of "heavy" users - they ALWAYS have this group in population
mix. Another question, what will be maximum resource consumption by this
group. In case of buffet or library, maximum consumption is limited by
natural constrains - you can "eat" and "read" only limited amount of
service. And what is more important - maximum consumed service is fixed per
user and not changed significantly over time. So whatever resources you
provisioned for given population today , it will be enough for tomorrow
service as well.

In case of flat-rate ISP dynamics is different - similarly to
"all-you-can-eat" buffet, "heavy" user can download/watch so much movies per
day, but... 
	(a) ISPs are not provisioned for those kind of content - like
"all-you-eat" buffet plan to serve a light breakfast, but serving lunch for
a football team
	(b) Video quality demand increased rapidly - and so traffic per
movie download. 

As result - 5%+95% of users are consuming more resources then provisioned or
make economical sense. And it is not because of those 5% - it is result of
changes in ALL user trends that probably break current technological or
economical assumptions.

And, btw - let's not "blame" this on P2P only. P2P just accelerated the
common trend - availability of the high-quality video content. Non-P2P video
downloads (mostly HTTP based) are accounted for about 20% of broadband ISP
traffic - second place after 40% associated with P2P. As more professional
content providers are coming into the play with legal content downloads,
proportion on non-P2P video expected to grow as well. And, btw, if P2P
traffic consumption can be shifted in time and space using some sort of BW
throttling and P4P routing, HTTP-based streaming do not provide such
flexibility as content has to be delivered NOW and from a single source. So
even if we remove P2P from equations, ISPs will face the same problems in
just 1-3 years due other forms of OTT video delivery.

Bottom line:
1.) flat-rate is not fair at any speed
2.) Any flat rate/free service have 5% of users consuming 50% of resources.
3.) As long as consumer Internet is a "dumb-pipe" with no ability to
differentiate on protocol/content, ISPs have to plan to over-provision up to
satisfy top 5% of users or , alternatively move to usage-based pricing (
which has its own economical and technological problems - separate
discussion)

IMHO, considering cost and problems of usage-based billing, I do not believe
that ISPs will move in mass to this new/old model. Probably, the better bet
is in direction of the making network more "smart" - and it is where IETF is
major driving force.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Jun 2008 14:42:47 -0400

I don't see how short term (second to hour) fairness is all that  
interesting to users. If I'm a light user overall, but want to watch a  
movie on-demand (p2p or CDN) during the "busy hour", why should I not  
be able to do this? How can you explain this "fairness" to a user?  
Users pay a monthly fee, so they probably expect rough value-for-money  
on that general timescale.

Henning

---

From: Richard Bennett <[email-masked]>
Date: Mon, 09 Jun 2008 12:00:22 -0700

I don't think there's anything in the notion of per-second end-user 
fairness that should preclude the use of P2P or CDN downloads during 
peak usage periods. It should only become an issue for you if you were 
watching a live stream and also peering some heavy P2P loads at the same 
time, and in this case you need to be able to communicate stream 
priorities to your ISP. If you can't communicate this information, then 
it will probably be OK for you to have the ISP do enough DPI to figure 
it out for you.

As others (most notably Nick) have pointed out, value-for-money in a 
residential broadband contract doesn't automatically equate to Committed 
Information Rate. These are statistical systems, where you get less than 
you pay for at some times and more than you pay for at others.

Accepting statistical multiplexing as a design constraint from the 
get-go will help this group make faster progress.

RB

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Jun 2008 15:03:59 -0400

On Jun 9, 2008, at 3:00 PM, Richard Bennett wrote:

> peak usage periods. It should only become an issue for you if you  
> were watching a live stream and also peering some heavy P2P loads at  
> the same time, and in this case you need to be able to communicate  
> stream priorities to your ISP. If you can't communicate this  
> information, then it will probably be OK for you to have the ISP do  
> enough DPI to figure it out for you.

The statement above implies a committed information rate, namely that  
of a single video stream. That's a reasonable service definition, to  
be sure.

> residential broadband contract doesn't automatically equate to  
> Committed Information Rate. These are statistical systems, where you  
> get less than you pay for at some times and more than you pay for at  
> others.

This has nothing to do with CIR, simply that fairness would argue, for  
example, that during peak periods, those who have already used "their  
fair share" of network resources this month get lower priority.

> get-go will help this group make faster progress.

The problem is that we'll get systems that are not going to work as  
advertised, from a user perspective.
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Richard Bennett <[email-masked]>
Date: Wed, 11 Jun 2008 16:44:41 -0700

Comment below:

> advertised, from a user perspective.
We already have such systems, largely because we don't know how to 
mandate meaningful disclosure. It strikes me as going the wrong way 
around to say that ISPs have to provide CIR because that's the only 
thing that can be adequately communicated to the customer in a way that 
he can't misunderstand. If we go that way, we lose the benefits of 
packet networking in the burst scenario and most of the economics go 
down the tube as well. So rather than back off statistical multiplexing, 
it strikes me as more beneficial to develop some standard metrics that 
enable consumer advocates, if not consumers themselves, to evaluate 
different services.

These metrics would include "mean information rates" at various levels 
of latency, the critical piece of a "buckets of packets" system. I'd 
like to be able to shop for an Internet access account that provided me 
with a bandwidth/latency profile that enabled me to successfully get one 
VoIP session through at the same time that three people surfed the web 
and four video stream downloads are in progress. There's no technical 
barrier to building such a network service, once the video stream 
downloads are managed as scavenger class activities (less that BE) and 
the VoIP is managed as a better-than-BE service.

But how would the ISP advertise this service? The terms that are needed 
aren't part of the marketing lexicon at the moment, so they really do 
need to be developed.

I mention this here because the next step after developing standards for 
P2P Infrastructure improvements, whether the system is based on optimum 
route discovery or caching, will be to communicate to the market that 
the system is in place and working at ISP XYZ. Are they going to say 
"Blazing Internet Service, now with Oracles and Scavengers!!!", or what?

RB

-- 
Richard Bennett

---

From: Daniel Weitzner <[email-masked]>
Date: Wed, 11 Jun 2008 20:36:37 -0400

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

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.

-- 
Daniel J. Weitzner                          +1.617.253.8036
Director, MIT Decentralized Information Group
Principal Research Scientist, MIT CSAIL
W3C Technology & Society Policy Director
http://www.w3.org/People/Weitzner.html
blog: http://people.w3.org/~djweitzner/blog/

---

From: Richard Bennett <[email-masked]>
Date: Wed, 11 Jun 2008 18:51:37 -0700

Comments in-line:

> and latency you pay for where those values are averaged over some  
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.
> 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