Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On Mon, 09 Dec 2013 06:37:05 +, Gary Buhrmaster said: It has been a long long time, but for the truly crazy, I thought it was possible to write single characters at a time (using a Set Buffer Address and then the character) as long as you had set up the field attributes previously. Lots of transactions, but one could appear to write out individual characters as slowly as the KSR 33 it replaced. Or perhaps my 3270 memory has finally faded away. AIX/370 supported vi on a 3278-2 console. Phear. pgpxWJRgwYm5E.pgp Description: PGP signature
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/8/2013 9:48 PM, Jay Ashworth wrote: Very specifically: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as faster than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. Interesting, but it doesn't feel like the one I'm vaguely remembering. (How's that for waffling?) But then, when interactive computing started getting real, by the late 60s and early 70s, a number of places started studying human-computer interaction issues. IBM and Bell Labs were the two places best positioned with researchers for this. Anyhow, my main point was that economic charging models that are entirely rational, with respect to consumption and cost, don't always work for user preference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
- Original Message - From: Phil Karn k...@philkarn.net On 12/06/2013 05:54 AM, Mark Radabaugh wrote: Currently, without a limit, there is nothing to convince a end user to make any attempt at conserving bandwidth and no revenue to cover the cost of additional equipment to serve high bandwidth customers. By adding a cap or overage charge we can offer higher speed plans. Why is that? Just guarantee each user a data rate that depends on how much he pays. Charge him by what it costs you to build and maintain that much capacity. Lots of mechanisms exist to do this: token bucket, etc. He gets more than his guaranteed capacity only when others don't use theirs. Otherwise he won't. If that's unacceptable to him, then he has the choice of paying you more to upgrade your network or waiting for others to stop using their guarantees. It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it. +10 We've forgotten the Committed Information Rate already? Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On Dec 9, 2013, at 11:38 AM, Jay Ashworth j...@baylink.com wrote: It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it. +10 We've forgotten the Committed Information Rate already? ATM/FRAME ftw? I think the challenge here is that RF doesn't scale similarly to other mediums. Cost per bit-mile on fiber is really low compared to RF. If you assume 10G-LR optics (10km) @ $299 *2 (pair) + Cvt-5002sfp ($500*2) is around $0.16/Mbit RF (cheap) NB-5G25 = $95*2 (pair) is around $3.16/Mbit (assuming 60Mb/s unidirectional) or almost 20x the cost, assuming 40Mhz channel and spectrum available. While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project. - Jared
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
- Original Message - From: Jared Mauch ja...@puck.nether.net While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project. You will perhaps recall that I put NANOG through teaching me that exact thing last Summer. :-) But Phil was talking about Wireline caps, unless I misunderstood him. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/9/13 2:03 PM, Jared Mauch wrote: On Dec 9, 2013, at 11:38 AM, Jay Ashworth j...@baylink.com wrote: It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it. +10 We've forgotten the Committed Information Rate already? ATM/FRAME ftw? I think the challenge here is that RF doesn't scale similarly to other mediums. Cost per bit-mile on fiber is really low compared to RF. If you assume 10G-LR optics (10km) @ $299 *2 (pair) + Cvt-5002sfp ($500*2) is around $0.16/Mbit RF (cheap) NB-5G25 = $95*2 (pair) is around $3.16/Mbit (assuming 60Mb/s unidirectional) or almost 20x the cost, assuming 40Mhz channel and spectrum available. While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project. - Jared Jared, It's a lot worse on RF if you want to be able to scale to 100 customers per tower site. Ubiquiti gear (NB-5G25) is dirt cheap but doesn't scale. To make it work with any kind of customer density you need Cambium, Radwin, Redline, or a manufacturer who has GPS sync working properly.70Mb = $3000 (AP + Sector antenna) + 400 (client equipment) for about $48.50/Mbit. LTE is significantly higher given base station cost and spectrum licensing. Letting customers use 'idle' bandwidth is great in theory but in practice it has a few problems. We have experience with this as we have allowed our users to burst to maximum available speed for many years. a) Customers become acclimated to burst speed. Customers complain bitterly if the speed test that used to say 20Mb now says 6Mb even though they are paying for 3.5Mb. The provider is obviously an evil bastard and gouging them while overloading the towers. b) Streaming video doesn't always deal well with changing speeds. Netflix essentially runs a speed test at the start of the stream to decide on a resolution. If it picks HD and then reaches the sustained limit (or in this model other users start requesting CIR bandwidth) Netflix does not always gracefully back down and results in a buffering or 'your connection has slowed' message. c) Trying to explain 'burst' to customers is difficult at best. Leaky bucket policers / CIR / etc. confuse engineers. Good luck getting Grandma to understand it. We regularly get customers who are confused between 5Mbps (our plans) and 5GB (cell phone plans). It's not unusual to lose a customer to a 'faster 5GB LTE connection for $40/mo' from a uncapped 5Mbps $54.95 service plan. It's really not surprising when you hear back from them 2 months later when they get a $400 bill from VerizaTT. I really like the new cell company game - no overage fees for the first 60 days, and you have 30 days to cancel your 2 year service plan if you don't like it. Mark -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015 x 1021
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/06/2013 05:54 AM, Mark Radabaugh wrote: Currently, without a limit, there is nothing to convince a end user to make any attempt at conserving bandwidth and no revenue to cover the cost of additional equipment to serve high bandwidth customers.By adding a cap or overage charge we can offer higher speed plans. Why is that? Just guarantee each user a data rate that depends on how much he pays. Charge him by what it costs you to build and maintain that much capacity. Lots of mechanisms exist to do this: token bucket, etc. He gets more than his guaranteed capacity only when others don't use theirs. Otherwise he won't. If that's unacceptable to him, then he has the choice of paying you more to upgrade your network or waiting for others to stop using their guarantees. It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it. Nothing says you have to carry a customer for less than your incremental cost of servicing his account, or that you can't add a reasonable profit margin. But if you can make your customers realize that they're paying you for a guarantee that most ISP users don't get now they may find it entirely worthwhile, especially given the very large economies of scale that often exist in data communications. --Phil
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/8/2013 7:55 PM, Phil Karn wrote: It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Sometimes, yes. Othertimes, perhaps not. I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. So, stability over throughput, sort of. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
- Original Message - From: Dave Crocker d...@dcrocker.net I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. Very specifically: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as faster than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/9/2013 12:48 AM, Jay Ashworth wrote: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as faster than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. This is a screen/block mode I/O issue versus a character-mode one. And the screen/block I/O won't start until the whole screen data is there, so there is an initial delay. The character-mode variant will paint portions of the screen as the data arrives. Similar anomalies exist on input... the screen/block mode is buffered locally and proceeds normally; while the character mode version has to transit the WAN link, whatever it may be. I won't argue that one is better than the other, depending on your link speed (transmitting a whole screen will incur longer delays than transmitting individual fields, though admittedly it happens less often). But the user perception goes a long way... I have seen advantages to both, having done serial termainal applications from back to the 1970s, and won't argue one way or the other. You choose your poison. With 3270 you have little choice other than full screen transactions. For other ASCII terminal interfaces, you could optimize the individual fields (while paying the full screen price). There are user perceived throughput values, transaction perceived throughput values, and application perceived throughput values. And very rarely did the three equal out for every application :( Jeff
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/8/2013 11:48 PM, Jay Ashworth wrote: - Original Message - From: Dave Crocker d...@dcrocker.net I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. Very specifically: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as faster than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. Back in the day we were building a system to run on UNIVAC equipment but some brainiac decided that because we were a Bell System company, we had to use DataSpeed 40's (which buffered the screen and snap it up when the last character is received) instead of the UTS terminals on which the system was developed (which painted each character as it came in. Users weeped and wailed to no effect that the change hurt them badly (which they could prove) because that while the two had the same time from first character to last, the operators could not start composing a reply when the first several lines had painted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On Mon, Dec 9, 2013 at 6:02 AM, Jeff Kell jeff-k...@utc.edu wrote: ... With 3270 you have little choice other than full screen transactions. It has been a long long time, but for the truly crazy, I thought it was possible to write single characters at a time (using a Set Buffer Address and then the character) as long as you had set up the field attributes previously. Lots of transactions, but one could appear to write out individual characters as slowly as the KSR 33 it replaced. Or perhaps my 3270 memory has finally faded away. Gary
Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/5/13 7:35 PM, Phil Karn wrote: On 12/05/2013 02:00 PM, Owen DeLong wrote: If ATT has capped me, then, I haven’t managed to hit the cap as yet. Admittedly, the connection isn’t always as reliable as $CABLECO, but when it works, it tends to work at full speed and it does work the vast majority of the time. ATT threatened to cap U-verse at 250 GB/mo several years ago, but they never seem to have followed through. It's probably about the only way that their incompetence is actually in the public interest. Monthly caps -- and even peak speed limits -- are a very poor idea in general because they don't take system conditions into account. A torrent that runs at night penalizes you just as much as one run at prime time. Actually more, since you probably get greater throughput at off-peak times and therefore hit your cap faster. If one *must* charge for usage on a shared network, the right thing is to base the monthly fee on *guaranteed* bandwidth because that's what actually drives costs. If more is available because others aren't using their guarantees, fine, you can have it for free. But it's not guaranteed. And you don't get a refund for not using your guarantee because the equipment still had to be allocated for you. Of course the real solution to nearly every problem with local broadband access is the same: meaningful competition. About the only way this could happen is for the municipality to install, own and maintain the fiber plant and lease it to any and all commercial service providers on a non-discriminatory and non-exclusive basis. Naturally this will never happen in the United States because the incumbents will scream socialism! at the top of their lungs and race to the state houses to outlaw it. Never mind that this is exactly how we've handled roads for centuries. --Phil Phil - we sort of do what you suggest, making the fee based on the sustained rate without a cap. The problem becomes one of being and staying competitive in the market. This method penalizes the light users in favor of the heavy ones. Amplex is a WISP so we are somewhere between wired and mobile wireless, though closer to wireline in many ways. Our limiting factors are sector capacity, spectrum availability, and physical tower space. By staying with relatively low speed plans (1, 3.5, 5, and 9Mpbs) we can reasonably guarantee that a user running full rate 24x7 will not significantly affect the other users on the sector. Keeping the speeds to low rates becomes a marketing/sales problem. It also keeps us from offering higher speeds to light consumption users. Currently, without a limit, there is nothing to convince a end user to make any attempt at conserving bandwidth and no revenue to cover the cost of additional equipment to serve high bandwidth customers.By adding a cap or overage charge we can offer higher speed plans. I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: Monthly_GBCountPercent 100GB 3658 90% 100-149 368 10% 150-199 173 4.7% 200-249 97 2.6% 250-299 50 1.4% 300-399 27 0.7% 400-499 9 0.25% 500-599 4 0.1% 600-699 4 0.1% 700-799 3 0.1% 800 1 0.03% Overall average: 36GB/mo The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015 x 1021
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/06/2013 05:54 AM, Mark Radabaugh wrote: I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: Monthly_GBCountPercent 100GB 3658 90% 100-149 368 10% 150-199 173 4.7% 200-249 97 2.6% 250-299 50 1.4% 300-399 27 0.7% 400-499 9 0.25% 500-599 4 0.1% 600-699 4 0.1% 700-799 3 0.1% 800 1 0.03% Overall average: 36GB/mo The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. Thanks for the stats, real life is always refreshing :) It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB? Mike
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On Dec 6, 2013 5:16 PM, Michael Thomas m...@mtcc.com wrote: On 12/06/2013 05:54 AM, Mark Radabaugh wrote: I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: Monthly_GBCountPercent 100GB 3658 90% 100-149 368 10% 150-199 173 4.7% 200-249 97 2.6% 250-299 50 1.4% 300-399 27 0.7% 400-499 9 0.25% 500-599 4 0.1% 600-699 4 0.1% 700-799 3 0.1% 800 1 0.03% Overall average: 36GB/mo The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. Thanks for the stats, real life is always refreshing :) It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB? Mike In a cell network, mr. Hog is most definately negatively impacting users on the same radio sector and backhaul, both of which are dimensioned and operated (like the internet as a whole) on statistical multiplexing. If mr hog is blasting 50mbs on a 100meg link 24/7, nobody will perceive 100mbs since 50mbs is always consumed by mr hog. Statistical multiplexing works great 99% of the time, and i personally would rather not engineer the whole system to fight the 1% extreme users CB
Re: Caps (was Re: ATT UVERSE Native IPv6, a HOWTO)
On 12/6/13 8:14 PM, Michael Thomas wrote: Thanks for the stats, real life is always refreshing :) It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB? Mike Thank you for the response! Mr. Hog impacts other customers in that he blows the over subscription model for that particular tower site (and specifically the sector) well out of the norm. This specific sector has a capacity of ~10.5Mbps download so his continuous 3.5Mbps is noticed by other customers. It's a last mile capacity issue, not a transit cost. Heck - transit is cheap these days and we have more than 50% spare transit capacity. Last mile is expensive. Most sites have sector capacities of 35 or 70Mbps (and Mr. Hogs will be updated fairly soon). What I'm really trying to figure out is how to offer higher speed packages (15Mbps or higher) without having a 24x7 user kill the over-subscription ratio or forcing a early upgrade to the tower site. I understand the argument that you should have full capacity available for the peak hour - but that peak hour doesn't really exist anymore with home users. The only real usage dropoff is from 12:30am to about 7am. Do the top 10% cause any problems? Not currently since we kept the available speeds low. What I am trying to figure out is how to offer higher speeds for the average user without having to resort to lots of weaseling in the marketing / AUP, etc. Putting some sane limits on the upper few percent seems to make the most sense. I'm not set on billing for overages. A rate limit at the cutoff would also be workable. I'm not willing to do the hidden cap / fire the top user method. Mark -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015 x 1021
