Subject: [aqm] Slightly off-topic: [Internet Policy] FCC's latest action - two questions

From: David Collier-Brown <[email-masked]>
Date: Sun, 27 Apr 2014 15:06:48 -0400

While this discussion is about policy, the implementation is either
- TCP flow/congestion control, or
- stream throtteling

>From dealing with providers of the latter, I'm not prepared to swear
that trying to implement the latter won't blow up the former (;-))

The on-topic question might be, will attempts to do network capacity
management necessarily interfere with congestion control and aqm.
I can certainly imagine
- a management tool attempting to artificially buffer and delay a
stream, adding far more latency than it restricts bandwidth, or
- a management tool forging aqm "slow down" signals, or
- discarding packets to force retransmission and slowdowns.

I wonder what's worst? Best?

--dave

-------- Original Message --------
Subject: Re: [Internet Policy] FCC's latest action - two questions
Date: Sun, 27 Apr 2014 19:40:34 +0100
From: Graham Cobb <[email-masked]>
To: [email-masked]

On 27/04/14 09:13, Patrik Fältström wrote:
> I do not get it either, and would like to have a clarification (if
> someone exists) from people  that have followed this closer than I
> have (I am trying to follow the European discussions, which fills
> my $day).

I do not know exactly what the FCC proposals mean, nor do I have any
insight into what the US ISPs want to do.  Full disclosure: my
employer supplies equipment to do policy control (and many other
things) to ISPs (including the US ISPs).  However, I have no knowledge
of their plans and, in any case, these comments are my own views, not
those of my employer.

However, I do know what some of the industry discussions (in many
countries) are about in this area, and what SOME ISPs (and vendors)
would *like* to do.

> Given these rules, it is already clear an access provider have two
> different ways of getting more money. A. negotiate other peering
> and transit relationships or B. charge downstream more for the
> Internet Access.

It is rather more complicated than that.  What many ISPs would like to
do is to sell all the parties involved in communication many
additional services (normally known as "value added services" -- VAS).
 For example, one service that someone like Netflix might be
interested in buying from an ISP is "charge to bill" -- allowing users
to charge the video rental to their phone bill.  But there are many,
many more services ISPs are hoping to sell to OTT (over-the-top)
players: marketing/advertising, space on their app store,
ordering/customer care, payments/charging, location, device
information, QoS, CDN/proxy, and loads more.

Many of those VAS have nothing to do with transmitting bits -- but the
ISPs want to bundle up many services and offer them as a package to
people like Netflix.

In addition, ISPs want to offer additional value added services to
their users.  One of those is bandwidth (another is latency --
particularly aimed at gamers, another is packet loss rates).  It is
fairly easy to see that in mobile networks, ISPs can offer users a
choice of maximum bandwidth (a trivial example is whether the user can
use 4G or is limited to 3G even where 4G is available -- in practice
there are a lot more options which allow many bandwidth choices to be
offered in both 3G and 4G networks).  In fixed line networks there is
less option to offer different access network speeds (although it does
exist) -- it is more normal to offer a choice of congestion options on
the backhaul (your access line may do 16Mbps but if you are sharing a
50Mbps backhaul between 50 people, you are unlikely to get more than
1Mbps at busy times).

The idea is that ISPs will offer different peak-time bandwidth, at
different prices: $10/month for 1Mbps, $20/month for 20Mbps, $35/month
for access to the maximum bandwidth available on your connection, say.
 Alongside those tiers, the ISP will offer a large number of options
to upgrade (permanently or temporarily, or for some protocols but not
others).  So, if you subscribe to 1Mbps speed but need 10Mbps to watch
a movie for the next 2 hours you could pay $2 to enable that (say).

The next step is to allow the OTT partner (Netflix, say) to pay that
add on fee for you.  So Netflix can say "watch this video for $5 even
if you only subscribe to the basic ISP service" -- and behind the
scenes Netflix would pay part of their $5 to the ISP to temporarily
configure your connection for a higher bandwidth for access to the
Netflix CDN, for the next 2 hours.

All this *could* be done without reducing the service level provided
to the users who are not paying for the add-ons (by careful
provisioning of access network and backhaul capacity). But will it? In
my mind, the questions for NN are these two:

1) Will the add-ons and VAS packages be offered equally, on FRAND
commercial terms, to all players, including the ISPs own services, and

2) Will the add-ons cause the basic service to become unusable or will
a reasonable level of service be maintained even for users who are not
paying additional charges (directly or indirectly).

> Because of this, to be able to implement "fast lane" connections
> must by definition be full.

No, it doesn't.  Modern policy control systems are very sophisticated.
 They can control the maximum bandwidth (and other traffic control
parameters, including whether access is allowed at all) available by
stream, identifying streams by a combination of source/destination IP
address, protocol etc, even using DPI to allow identification of
particular web sites or even particular pages within protocols such as
HTTP.  Rules can be created which use that information along with
subscriber info and preferences, device type, previous history,
quotas, limits, tier, add-ons, location, service being accessed, etc,
etc.  And third party web services (or apps on the device) can use
APIs to request (and pay for) changes to those rules.

The sorts of deals being talked about using this equipment would be
"buy a new Samsung HD tablet and get 20 days free Netflix upgrade to
HD from any location in central Mumbai".  Or "buy a new pair of
football boots from this store and get free access to all the
Manchester United goals on every Saturday afternoon of the season".
Or even "disable your access to porn videos for the upcoming religious
period and have us send an SMS to your priest to confirm you have done
it"!  The ideas are limited only to the imaginations of the marketing
depts.

Some of these are probably good ideas.  The question is how to allow
them without also allowing undesirable effects.

Graham
_______________________________________________
To manage your ISOC subscriptions or unsubscribe,
please log into the ISOC Member Portal:
https://portal.isoc.org/
Then choose Interests & Subscriptions from the My Account menu.

---

From: Alex Elsayed <[email-masked]>
Date: Mon, 28 Apr 2014 00:12:35 -0700

Well, I doubt any one option will be an absolute worst/best - simply because 
there are multiple metrics at play here, which likely conflict.

- How much overhead is added (retransmission, extra computation)?
- How easy/likely is the mechanism to be bypassed?
- If it is bypassed, how much damage does that do elsewhere?
- How likely is it to break other protocols?

For instance, interposing with some sort of TCP-level proxy that does CC 
differently on each side (this is already done in some cases for e.g. high-
latency links) adds little network overhead but potentially significant 
computational burden, is bypassed by using UDP (which may do significant 
damage if poorly implemented, potentially causing Yet Another Congestion 
Collapse), and breaks the end-to-end property of TCP flow control.

Throttling by packet-drop adds retransmission overhead, but very little 
computational. It's also only possible to bypass if you manage to evade 
whatever the classification scheme is, and is unlikely to break any protocol 
since it's an expected failure mode of the internet.

Throttling by ECN saves the retransmission overhead, but makes it easier to 
bypass (ignore the ECN bit), and might cause major long-term damage by 
providing an incentive to ignore ECN entirely. Again, however, it's unlikely 
to break other protocols _directly_.

Overall, it starts looking like the solution is the same as the basic case 
of AQM, in the rough:

1.) If something is too fast, and ECN is supported, ECN
2.) If no ECN, drop
3.) If ECN but stream does not respond, drop (perhaps with penalty)

You then do some sort of weighted FQ, and use some sort of ruleset to 
control the weights and streams of each queue.

---

From: Wes Felter <[email-masked]>
Date: Mon, 28 Apr 2014 15:57:15 -0500

I would expect ISPs to disable (or never enable) AQM on the "slow lane" 
to maximize the difference between the two services. After all, people 
won't pay for the fast lane if it's the same speed as the slow lane.

-- 
Wes Felter