From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm13-vm9.access.bullet.mail.gq1.yahoo.com (nm13-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B544421F1CF for ; Sun, 27 Apr 2014 12:06:51 -0700 (PDT) Received: from [216.39.60.166] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Apr 2014 19:06:50 -0000 Received: from [67.195.22.118] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Apr 2014 19:06:50 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 27 Apr 2014 19:06:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1398625610; bh=QktU5tDG2FBNyNvmRjc2l+CmzQgho4mp4kwWf53KN0s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; b=tHP/q3TkGvCxfsUH62eQWCJtyMZNKe4wLKSMobaqon1CSa0bkjyywbYfURqX7D6UuoA2RfjDY7m5XPZEECHBLfkczVpOLs2Gnz6u5x49rOtn9dukPgEEjBqaf/rttXHBDEJ0BN4ewNG8C6L7tfdBtlM4ALAwcBCS77FYVuWMn6k= X-Yahoo-Newman-Id: 705177.71730.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DOWxPtYVM1mDR2C6j.MrIoI.ylm5iGhF9zk9Iy7_QzsrLuR JjhWpjfcycW_C59nkEc.heIpeB7uVYxNNutT4Tso1ohUYDlaHlC6_lLM8Vxr kZD14PzSeaDycJAczEmJ4VYh80L0z7OqdS_lCJiMI08O2R419GgwuoWinHl0 vvHoJ8CXbDhJW3.L3Lif3KplnQUyVg.gjwTbaV4yi_yA10DiXaXW4tGZYXYL ombTFCjW.81pr9PZAOKy90GBkL_e9XFAdzBtgwK6iOm8UYhuIMJoTn4xt0UH Hyl_N8P0mzPXCbxbH_gkgM8irUfblo6y7MdYnjcbkBKgGVWFYjQaxVyWIAGf kY3sNAWmEu5rOvtSDQ7tPz2MjlsJ7Q3In.vtyCiomrdtK0TUGR4wnoKjKAFJ LB21wyUhTcwuT2q1lzoYuC2zi_99gRLDP3Pewg8ixzQAWbJaAguZ9WcmCnS0 8ud_XuUqULMENdHp4Uo567zuTTVftjjfxMq5LtFTSVQHosVAGKhnVvh20iwo 7JjI_n2jhFM7YC4RniatMf9Dq51F2yL6alQ0adbpszW6lUVgFTQeLU0shCtM B.iWRUSHPvtzQ2h1Ukvuv6QrVxbctxN7ZEPsQiQ-- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- X-Rocket-Received: from [192.168.0.13] (davec-b@99.225.150.135 with plain [67.195.22.104]) by smtp113.sbc.mail.gq1.yahoo.com with SMTP; 27 Apr 2014 12:06:50 -0700 PDT Message-ID: <535D5548.1000208@rogers.com> Date: Sun, 27 Apr 2014 15:06:48 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "aqm@ietf.org" , bloat@lists.bufferbloat.net References: <535D4F22.6060602@cobb.uk.net> In-Reply-To: <535D4F22.6060602@cobb.uk.net> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <535D4F22.6060602@cobb.uk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Bloat] Slightly off-topic: [Internet Policy] FCC's latest action - two questions X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 19:06:52 -0000 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 To: internetpolicy@elists.isoc.org 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.