[p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable...

The following is a bunch of semi-random thoughts, mostly addressed at  
the notion that user fairness enforced in the network is an  
unacceptable solution, and that traffic management should not  
discriminate based on protocol.

For those who think "User Fairness"/"Cost Fairness" is unacceptable:   
Which would you rather have

a)  Usage based pricing/usage caps
b)  App manipulation/prioritization/blocking [1]
c)  User-based fairness

It has got to be one of the three as long as 5% of the users use >50%  
of the bandwidth, and as long as you have effectively misbehaving  
users and applications centered around flow-fairness, because there is  
no economic model which justifies adding more bandwidth when the  
5%-10% users benefit but the 90% don't see a benefit when the pricing  
is flat rate.

Its only if you no longer have the heavy tail that adding more  
bandwidth makes sense in flat pricing. [2]

And if instead of statistical multiplexing, you want committed or at  
least semi-committed bandwidth (the "They sold me a 16 Mbps link, so  
where is my 16 Mbps?" argument), there is a reason it is vastly more  
expensive.  Talk to a commercial ISP about a 1.5 Mbps T1 with a  
service level agreement, and compare that to the cost of your "16  
Mbps" cable-modem.

Additionally, there is a reason why I believe the example given by Mr  
Topolski of fairness disrupting a VoIP 911 call "ridiculous".

This argument seems to rests on the assumption that limiting a heavy  
user to some non-zero fair fraction of a total pipe would disrupt a  
VoIP 911 that is concurrent with a user's other activity [3], but at  
the same time, insist that the ISP should not take action to limit  
other users who disrupt the pipe (which is the current situation where  
some users are opening up 1/2 a dozen torrents simultaneously) which  
has been shown in practice to disrupt VoIP calls?

I will also argue there is a compelling case for protocol  
discrimination by the ISPs.  For example, users would benefit if the  
ISP shaped their flows just enough to keep the send buffers on the  
cable/DSL modems reasonably empty using delay-based heuristics, even  
when there is NOT congestion in the overall network, just the upload  
limit for the access device.

Instead, the current model means you can't make a VoIP call if someone  
in your household is doing too much BitTorrent (see, http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx 
  ), which is obviously an unacceptable situation.  Such "remote queue  
management" shaping would improve everybody's quality of service.

And when the ISP determines that a user is using too much bandwidth  
for any reason, be it user fairness, congestion, queue occupancy, or  
the capricious whims, should the ISP be completely blind about  
dropping packets?

Or should the ISP, when it can reasonably infer user intent but in the  
absence of explicit guidance, prioritize traffic based on inferred  
usage? [4]

Finally, I think there is a misunderstanding in the implications of  
how Comcast is proposing to implement fairness:  All they need to do  
is ensure that the usage of the "default priority" users is  
significantly less than the total channel capacity, and that whenever  
"default priority" traffic grows above that fraction, the heaviest  
default priority users are shifted into the low priority category.

As a result, the default priority (the low-bandwidth users) see no  
congestion and are happily statistically multiplexed, see low latency,  
and all the good they would expect.  As these are the bulk of the  
users, the ISP is therefore mostly happy.

And the "low priority" users will still have bandwidth, and they will  
still enjoy the current best-effort free-for-all: so if they could  
make their VoIP 911 call before, they probably still can (assuming the  
competing traffic is at least SOMEWHAT congestion responsive).  And if  
they couldn't before, its not like the situation was made worse. [5]   
Its just their best effort free-for-all can no longer step on the low  
volume users.

Yes, it would be a much better world if cable and DSL devices weren't  
overbuffered, if end-hosts would correctly mark prioritization of  
packets, if bulk-data P2P used congestion control that was friendly to  
standard TCP, if ISPs actually provisioned more bandwidth per user, if  
there were no worms, viruses, spam, spit, etc...   But we are living  
in a grossly impure and imperfect world, and we may have to accept  
grossly impure and imperfect solutions.

[1] And I suspect there is a LOT more of the app-based/usage based  
manipulation  going on than anyone is willing to admit.

EG, even relatively benign policies (eg, limit seeding to 2 peers when  
there is no other activity, blocking leeches in normal mode on  
BitTorrent.  This is a policy which actually helps most/all of the  
ISP's users at the expense of the rest of the swarm) can get really  
hostile responses.

Such manipulation would be REALLY hard to detect when done using  
inline shapers rather than out-of-path devices, or even with out-of- 
path devices which use ACL blocking instead of RST injection.

[2] The other way to get much more bandwidth is to either have large  
government subsidies (which again, would only really help the 5%-10%  
heavy users, eg the Japanese experience) or to have a situation like  
Verizon's FiOS, where they are pulling fiber to develop a CableTV  
competitor.  That it gives good Internet performance is in many ways a  
happy side effect of pulling modern physical media.

[3] The further example of it being an image upload is also not well  
chosen.  A single TCP flow will easily adapt and not really interfere  
with the (no congestion control) VoIP call, even on a relatively  
narrowly throttled pipe.  It is the problem when you have dozens of  
TCP flows (BitTorrent as used by some individuals), or large non- 
responsive UDP flows (Joost), or device send buffers which are overly  
large (which could get filled to frightening-jitter capacities on  
upload-limited flows).

[4] Traffic analysis, rather than DPI, is sufficient.  Bulk data P2P  
is just that: bulk data and P2P.  Streaming downloads from Youtube  
don't look like VoIP calls.  Very simple heuristics can distinguish  
these classes of traffic, and because of their inherent properties,  
you can't make bulk data P2P look like VoIP.

Although some DPI could help:  EG, YouTube and other flash-based  
streaming sources tends to operate in two modes: underbuffered (where  
the play rate is less then the bandwidth, and the user has to wait) or  
overbuffered (where the flash app downloads the video much faster than  
it is able to be watched, and the user may often download most of the  
video while watching only a little.).

Since YouTube does have the ability to seek, it would be of benefit to  
the user, if shaping needs to occur, if the shaping on a YouTube video  
was just enough to minimize the amount of overbuffering, as that would  
match the user's data rate with the consumption rate.

The only user penalty would be a greater delay when skipping forward,  
but the savings would be substantial if streaming video flash apps are  
unwilling to calibrate their buffering better.

[5] This may be a weakness of Comcast's proposal: its not fair ENOUGH.

Because it really only allocates into two categories rather than per  
user ceilings, you might have a case where, eg, a user is doing a  
single heavy TCP flow, enough to get bumped into the "Low priority"  
category where it gets stomped on by people doing many-flow  
transfers.  Thus it can preserve behavior for the lighter users, it  
doesn't necessarily help the heavy users who are using a few  
connections vs the many connection heavy users.  Thus its only a  
partial fairness rather than per-user fairness.

In fact, depending on parameters, you might have thrashing situations  
where a user with one heavy TCP flow is swapped back and forth between  
categories as the bandwidth usage goes way down when that one TCP flow  
has to compete among many flow usage.

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