how-to block ads
|
Share Topic
 |
 |
|
|
| | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:One way to solve stupid metered billing is to use a network layer protocol or extension to embed the pricing informationin the packet, and let the consumer enter his willingness to pay for each packet. Each packet is priority forwarded by the amount the consumer is paying for the packet. There needs to be an RFC for this type of protocol. Once a standard is laid, the telcos will more easily adopt it. Of course the move to IPv6 is slow going, so any implementation of such a protocol probably wouldn't happen for 20 years. Uhhh, no. The best method of billing doesn't require a new protocol or screwing around with existing protocols. Google the term "95th percentile billing". While I'm not a fan of forcing consumers to ration their use through usage based billing, 95th percentile billing is the fairest method of billing for usage and is already well established in the industry. The only downside is that the majority of people would be intimidated by its perceived complexity.
--
Kilroy was here | |
|  | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:said by anderboy:One way to solve stupid metered billing is to use a network layer protocol or extension to embed the pricing informationin the packet, and let the consumer enter his willingness to pay for each packet. Each packet is priority forwarded by the amount the consumer is paying for the packet. There needs to be an RFC for this type of protocol. Once a standard is laid, the telcos will more easily adopt it. Of course the move to IPv6 is slow going, so any implementation of such a protocol probably wouldn't happen for 20 years. Uhhh, no. The best method of billing doesn't require a new protocol or screwing around with existing protocols. Google the term "95th percentile billing". While I'm not a fan of forcing consumers to ration their use through usage based billing, 95th percentile billing is the fairest method of billing for usage and is already well established in the industry. The only downside is that the majority of people would be intimidated by its perceived complexity. A discussion of the pitfalls of this billing model, especially for internet end users:
»www.servicelevel.net/rating_matt···ue13.htm
--
My BLOG .. .. Internet News .. .. My Web Page
| |
| | | | Re: Metered billing coming - for telcos & cable; reason video Yes, 95th percentile billing does have its drawbacks, however, it works better than any other billing method out there. Remember, if the goal is to bill customers an amount based on their impact on the network, basing their bill on their bandwidth footprint makes more sense than pay per GB. It makes even more sense when you are being billed by your upstream based on the number of Gbps you use, not based on the number of GBs you transfer.
--
Kilroy was here | |
|
| | I don't see any evidence that 95th percentile billing is "the fairest method of billing." I believe it is more fair than many methods, but a bid based packet payment has many more advantages.
First of all, 95th percentile billing is all about how much one should pay based on statistics taken over a period of time. There is no feedback to the network, so it does not directly solve quality of service in the face of congestion. Perhaps it reduces it indirectly by deterring the torrent freaks from using 100% link capacity all month, but congestion scenarios are still handled by the network in the same way, which is bad.
It is MORE fair to base forwarding priority on the price of a single packet. Even in the face of network congestion I can choose to pay more in real time, and still get great service because my packets are send to the front of the forwarding queue.
Also it is MORE fair because I only pay for what I actually use, and it's not based on some statistical sampling.
It's also great for the torrent freaks, because when the network is not saturated, they can still saturate their own link with best-effort packets for relatively little money. | |
| | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:I don't see any evidence that 95th percentile billing is "the fairest method of billing." I believe it is more fair than many methods, but a bid based packet payment has many more advantages. I disagree, especially when you are talking about adding additional protocols or extension to protocols.
Additionally, since there in no "bid based packet payment" system in place, you can't argue for its advantages since it has never been tested, much less actually designed.
First of all, 95th percentile billing is all about how much one should pay based on statistics taken over a period of time. There is no feedback to the network, so it does not directly solve quality of service in the face of congestion. Perhaps it reduces it indirectly by deterring the torrent freaks from using 100% link capacity all month, but congestion scenarios are still handled by the network in the same way, which is bad. 95th percentile is a billing scheme only. We're talking about billing users for usage. We're not talking about some armchair network engineer scheme for traffic management. Methods already exist for dealing with QoS and traffic management and frankly, we don't need one that interfaces with the billing systems.
It is MORE fair to base forwarding priority on the price of a single packet. Even in the face of network congestion I can choose to pay more in real time, and still get great service because my packets are send to the front of the forwarding queue. Do you even know what you are talking about? Do you even realize what type of changes would need to be made to the network to accommodate this scheme of yours? I'm fairly certain you don't.
You are talking about creating a system, whereby in real time, any user can jump up and down the packet queues based on what sounds like bidding for priority. Such a system would create far more problems than it would solve. First, it would create a lot of room for abuse. Second, it only exacerbates the problem of some users "monopolizing" network resources - better financially endowed users or groups of users could simply outbid everyone and consume more than their share of the network resources. Third, the average user would quickly be confused by such a ridiculous scheme. Fourth, it creates extra and unnecessary headaches for the engineers and administrators at the provider. And on and on and on...
Also it is MORE fair because I only pay for what I actually use, and it's not based on some statistical sampling. Nope, you have it backwards. Learn how the 95th percentile system works and you'll see why this statement is incorrect. The reason the 95th percentile system makes sense is because as the users quantifiable impact on the network increases, so do their costs. You are actually paying for your share of the bandwidth used on the network.
That's the whole point. Providers buy their bandwidth in terms of Mbps and Gbps, not by the GB and not using some half-baked "bid based packet payment" system. Each user has a footprint in a given month, which can be quantified by kbps, Mbps or, for businesses, Gbps. It is much easier to create a payment scheme based on the number of kbps a user utilizes; it is also much easier to plan for capacity when everyone is tracked by the number kbps and Mbps used.
--
Kilroy was here | |
| | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:I disagree, especially when you are talking about adding additional protocols or extension to protocols. Additionally, since there in no "bid based packet payment" system in place, you can't argue for its advantages since it has never been tested, much less actually designed. That's what engineering is all about. You argue about advantages BEFORE it's been tested or designed.
said by NetAdmin1:95th percentile is a billing scheme only. We're talking about billing users for usage. We're not talking about some armchair network engineer scheme for traffic management. Methods already exist for dealing with QoS and traffic management and frankly, we don't need one that interfaces with the billing systems. I was talking about billing also. And we DO need a billing system that interfaces with QoS. Yes there are methods for dealing with QoS, many of which have been tested. But they are not implemented for the consumer. Why? Because they DO NOT FIT with the ISP's bottom line.
What ISP is going to buy equipment that identifies streams for Integrated Services, when there is no profit benefit? There is even more room for abuse in that system since I can just send any data I please over whatever is the highest priority protocol. But of course, IntServ has already been rejected by the community as a whole.
DiffServ is another method that is only a precursor to the bid-based packet scheme. There are MULTIPLE queues with different PRIORTIES based on the DSCP field. ISPs would charge MORE for higher PRIORITIES.
However this also has NOT been implemented in the internet. My post is advocating for such a system because IT IS INTRINSICALLY LINKED TO BILLING.
said by NetAdmin1:Do you even know what you are talking about? Do you even realize what type of changes would need to be made to the network to accommodate this scheme of yours? I'm fairly certain you don't. Of course there will be changes. But it is only an evolution of Diffserv, which MANY ROUTERS ALREADY SUPPORT.
said by NetAdmin1:You are talking about creating a system, whereby in real time, any user can jump up and down the packet queues based on what sounds like bidding for priority. Such a system would create far more problems than it would solve. First, it would create a lot of room for abuse. Every system has abuse. Currently I can blast all the traffic I want and make everybody's connection suck, at no cost to me. Be more specific.
said by NetAdmin1:Second, it only exacerbates the problem of some users "monopolizing" network resources - better financially endowed users or groups of users could simply outbid everyone and consume more than their share of the network resources. Since they paid for it, IT IS THEIR SHARE. These are ISPs with shareholders to answer to, not some government support program.
You would have the entire backbone bandwidth divided equally for every damn user? What is "fair" to you, if it involves no incentives like money?
said by NetAdmin1:Third, the average user would quickly be confused by such a ridiculous scheme. The average user need not know about the scheme unless they want to hand tune their services and billing. The average user may only use best effort packets, which would require no knowledge or configuration, no different than it is now.
said by NetAdmin1: Fourth, it creates extra and unnecessary headaches for the engineers and administrators at the provider. And on and on and on... That's what we do for profit. Given that the ISP has a monopoly on its own bandwidth, this scheme guarantees the maximum profit for the ISP. It is first degree price discrimination, which is entirely economically efficient. Those that are willing to pay the most do, and those that are willing to pay some, also do. Look up price discrimination.
said by NetAdmin1:Nope, you have it backwards. Learn how the 95th percentile system works and you'll see why this statement is incorrect. The reason the 95th percentile system makes sense is because as the users quantifiable impact on the network increases, so do their costs. You are actually paying for your share of the bandwidth used on the network. Ummm, no. From wikipedia:
"Criticism for end user billing:
With the 95th percentile billing method there is potential for paying for bandwidth that is not used."
So obviously bandwidth that is not used is not "your share of the bandwidth."
said by NetAdmin1:That's the whole point. Providers buy their bandwidth in terms of Mbps and Gbps, not by the GB and not using some half-baked "bid based packet payment" system. Each user has a footprint in a given month, which can be quantified by kbps, Mbps or, for businesses, Gbps. It is much easier to create a payment scheme based on the number of kbps a user utilizes; it is also much easier to plan for capacity when everyone is tracked by the number kbps and Mbps used. Well, obviously that needs to change for any fair priority based system to work. Easy is desirable, but profit is MORE desirable.
A users footprint is not only quantifiable in terms of data transfered, but in the size of the individual packets and the congestion of the network at the time of data transfer. To be completely fair, these have to have some effect on the price as well. A bid-based scheme takes these into account automatically. | |
| | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:That's what engineering is all about. You argue about advantages BEFORE it's been tested or designed. This bidding system sounds like economics professor's solution to a technical issue. Based just on your non-technical description, I can list a number of engineering issues with such a scheme already. And that probably is why there is no push amongst the network engineers out there to use a "bid based" scheme.
I was talking about billing also. And we DO need a billing system that interfaces with QoS. Why? What technical reasons are there for tying the billing system to QoS in the manner you outlined? And can you list any of the potential changes that need to be made to do this and what types of issues they would create?
Yes there are methods for dealing with QoS, many of which have been tested. But they are not implemented for the consumer. Why? Because they DO NOT FIT with the ISP's bottom line. The bottom line really has nothing to do with it because the costs of implementing basic QoS are negligible. QoS features are already built into most of the routers that ISPs use, so there is typically no additional cost in implementing it. Implementing a simple system that gives real time traffic, ie- VoIP, priority over other traffic is not time consuming either.
The reasons have little to nothing do with the bottom line.
But of course, IntServ has already been rejected by the community as a whole. IntServ was rejected because it scales poorly. You can't use IntServ on a network with traffic volumes like access networks and the Internet without complex designs for engineering the flows.
DiffServ is another method that is only a precursor to the bid-based packet scheme. There are MULTIPLE queues with different PRIORTIES based on the DSCP field. ISPs would charge MORE for higher PRIORITIES.
However this also has NOT been implemented in the internet. My post is advocating for such a system because IT IS INTRINSICALLY LINKED TO BILLING. No. Once again, the reasons that we don't have DiffServ, like IntServ, on the internet are for technical, not economic, reasons.
Since they paid for it, IT IS THEIR SHARE. These are ISPs with shareholders to answer to, not some government support program. So, if they pay enough, they can effectively block everyone else out of the network. Yeah, there is no problem there... 
Ummm, no. From wikipedia:
"Criticism for end user billing:
With the 95th percentile billing method there is potential for paying for bandwidth that is not used."
So obviously bandwidth that is not used is not "your share of the bandwidth."
See the word "potential". Most home user activity is such that the potential problem will never affect them. Most home users do not run their connections full bore, 100% utilized for 36+ hours straight, once a month. Those home users that have that pattern of usage should pay more if usage based billing is used.
And the phrase "bandwidth that is not used" is not accurate. You are paying for the bandwidth you have used, but it is not bandwidth you use a majority of the time (the average bandwidth). What you are paying for is the bandwidth used during the period when your usage impacts the network the most.
If that is your criticism for 95th percentile billing, then average billing is your friend.
Well, obviously that needs to change for any fair priority based system to work. Easy is desirable, but profit is MORE desirable. ISPs are already making profits and without the additional complexities of engineering such systems for "bid based" contention.
--
Kilroy was here | |
| | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:Why? What technical reasons are there for tying the billing system to QoS in the manner you outlined?
In such a system there is no need to avoid congestion. It is a non-issue because any service can be provided in the presence of congestion, provided the consumer pays enough. It makes traffic shaping, scheduling, and congestion avoidance obsolete.
It is completely fair economically. You pay for what you use.
It boosts ISPs profits. Why wouldn't they want that?
However many consumers would not benefit, given that the wealth is transfered to the ISP and not to the consumers in this price discrimination.
said by NetAdmin1:And can you list any of the potential changes that need to be made to do this and what types of issues they would create? Peering agreements may need to be changed, which is why I understand that differentiated services is not yet available for consumers on the internet. Just because you pay your ISP some amount of money doesn't mean a peer will give the same priority. How is the money divided among the networks? I believe these issues can be solved given the benefit of this scheme to the ISPs as a whole.
said by NetAdmin1:The bottom line really has nothing to do with it because the costs of implementing basic QoS are negligible. QoS features are already built into most of the routers that ISPs use, so there is typically no additional cost in implementing it. You misunderstand me: I'm not talking about being implemented in hardware or software, I'm talking about being available for the consumer to use. Although it may be "implemented" in a router it is not currently implemented in the internet. I can't ask AT&T to please give me a special quality of service for my video conference. Why would the ISP give my video conference priority if I didn't pay any more for it?
said by NetAdmin1:Once again, the reasons that we don't have DiffServ, like IntServ, on the internet are for technical, not economic, reasons. What technical reason? DiffServe scales just fine. Wikipedia lists economic concerns of peering agreements as the primary reason for not using DiffServe. The same reason could be cited as reason not to use a bid-based packet scheme.
said by NetAdmin1:So, if they pay enough, they can effectively block everyone else out of the network. Yeah, there is no problem there. They can only use as much as their link speed gives them. I don't see it as much more of a problem than exists now. Currently I can saturate my link with garbage at no cost to me, with considerable cost to others. I'm sure the ISP wouldn't mind if a single entity is paying for all the bandwidth if the ISP is getting all of the revenue. Why should they care who pays? They want profit. | |
| | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:In such a system there is no need to avoid congestion. It is a non-issue because any service can be provided in the presence of congestion, provided the consumer pays enough. It makes traffic shaping, scheduling, and congestion avoidance obsolete. That is a pipe dream. Congestion will always be an issue when you oversubscribe the available bandwidth upstream from the users.
Peering agreements may need to be changed, which is why I understand that differentiated services is not yet available for consumers on the internet. Just because you pay your ISP some amount of money doesn't mean a peer will give the same priority. How is the money divided among the networks? I believe these issues can be solved given the benefit of this scheme to the ISPs as a whole. Good luck with that. For this to work, everyone would have to use the same DSCP values across the board. Backbone providers, who have no shortages of bandwidth won't invest the time in messing with DSCP because they don't need it.
I can't ask AT&T to please give me a special quality of service for my video conference. Why would the ISP give my video conference priority if I didn't pay any more for it? There already is a level of service for this already. It is called business class internet.
What technical reason? DiffServe scales just fine. Wikipedia lists economic concerns of peering agreements as the primary reason for not using DiffServe. The same reason could be cited as reason not to use a bid-based packet scheme. First and foremost that every network would have to use the same DSCP values for each class of traffic AND assign it the same queue priority. That isn't an economic issue, that is a technical and political issue.
Also, when you have congestion and de-prioritized classes of traffic are discarded, you create issues with TCP flows and retransmits. You essentially make more problems.
They can only use as much as their link speed gives Right, which in some cases is enough to cause problems for other users. For example, imagine three wealthy or business users with 15Mbps service on the same cable node as poorer users. If the users with more cash bid up their priority and run at full utilization, they can negatively impact the traffic of many other users. That is not fair or good business sense.
--
Kilroy was here | |
| | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:That is a pipe dream. Congestion will always be an issue when you oversubscribe the available bandwidth upstream from the users. You give no explanation. How is congestion an issue? It's only an issue for those who don't want to pay the market rate.
said by NetAdmin1:For this to work, everyone would have to use the same DSCP values across the board. That's pretty naive. That's like saying a VC identifier has to be the same across an entire ATM network. There are forwarding tables for a reason.
said by NetAdmin1:Backbone providers, who have no shortages of bandwidth won't invest the time in messing with DSCP because they don't need it. They'll do it when they see enough money in it. If they aren't using the entire bandwidth, then they're losing money. Read about opportunity costs.
said by NetAdmin1:There already is a level of service for this already. It is called business class internet. This may get me special treatment on AT&T's network, but not on anyone else's. End to end QoS is not possible in the current internet.
said by NetAdmin1:First and foremost that every network would have to use the same DSCP values for each class of traffic AND assign it the same queue priority. Again, DSCP values can change among networks, just need a simple translation table. That is not a problem. The priority is always relative to the other packets on THAT network. The peering agreements would provide the information to construct the translation tables.
said by NetAdmin1:Also, when you have congestion and de-prioritized classes of traffic are discarded, you create issues with TCP flows and retransmits. You essentially make more problems. This has nothing to do with de-prioritized classes of traffic. TCP will cut back on its transmit rate just as in normal congestion scenarios. Congestion is congestion. There already exists congestion. Currently, if the TCP user can't stand the congestion, then there is nothing for it. Too bad. With a bid-based scheme, the user can choose to pay more and avoid the congestion.
said by NetAdmin1:Right, which in some cases is enough to cause problems for other users. For example, imagine three wealthy or business users with 15Mbps service on the same cable node as poorer users. If the users with more cash bid up their priority and run at full utilization, they can negatively impact the traffic of many other users. That is not fair or good business sense. This can ALREADY occur on the current internet. If three business users with fat pipes are blasting traffic, the others will get hardly any. At least with a bid-based system it maximizes profits, so it IS good business. | |
| | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:You give no explanation. How is congestion an issue? It's only an issue for those who don't want to pay the market rate. If I oversubscribe the bandwidth on my network, which will not go away, congestion will always be an issue. ISPs don't sell bandwidth in at a 1:1 contention ratio because the costs of doing so are too high. So if you have a neighborhood with 100 households attached to a DOCSIS node, you have 100 homes in contention for 38Mbps of bandwidth. IF you reach a point where all the users are using the network at the same time, your available bandwidth is shared and there will be congestion.
That's pretty naive. That's like saying a VC identifier has to be the same across an entire ATM network. There are forwarding tables for a reason. This is from Wikipedia, since you are so found of that site:
quote:
End-to-end and peering problems
One disadvantage is that the details of how individual routers deal with the type of service field is somewhat arbitrary, and it is difficult to predict end-to-end behaviour. This is complicated further if a packet crosses two or more DiffServ clouds before reaching its destination.
From a commercial viewpoint, this is a major flaw, as it means that it is impossible to sell different classes of end-to-end connectivity to end users, as one provider's Gold packet may be another's Bronze. Internet operators could fix this, by enforcing standardised policies across networks, but are not keen on adding new levels of complexity to their already complex peering agreements. One of the reasons for this is set out below.
Diffserv operation only works if the boundary hosts honour the policy agreed upon. However, this assumption is naive[citation needed] as human beings rarely agree. A host can always tag its own traffic with a higher precedence, even though the traffic doesn't qualify to be handled with that importance. This in fact has already been exploited: Microsoft Windows 2000 always tags its traffic with IP precedence 5, making the traffic classing useless. On the other hand, the network is usually quite within its rights to traffic shape and otherwise ration the amount of network traffic ingress with any particular precedence, and so where this is enforced, overall network traffic flow provided to a host could be reduced by such a tactic.
Translation of the DSCP tags still doesn't guarantee that the packet will receive the same priority in the next AS or three or four ASes down the line. Hell, one AS might not even have DSCP setup or may strip DSCP values.
They'll do it when they see enough money in it. If they aren't using the entire bandwidth, then they're losing money. Read about opportunity costs. That is the thing, there is no money in it. Backbone provides have enough bandwidth that screwing around with DiffServ doesn't make sense. They have no shortage of bandwidth like some of the last mile providers.
This can ALREADY occur on the current internet. If three business users with fat pipes are blasting traffic, the others will get hardly any. At least with a bid-based system it maximizes profits, so it IS good business.
So, basically, your scheme does nothing to fix the problems of network congestion and over-subscription, except to maybe boost the operators income... However, if everyone just pays the lowest rate possible for their packets, like they do for other things, then basically you see no improvement in cash flow.
Your scheme operates on far too many assumptions about the network and how users will pay.
--
Kilroy was here | |
| | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:If I oversubscribe the bandwidth on my network, which will not go away, congestion will always be an issue. ISPs don't sell bandwidth in at a 1:1 contention ratio because the costs of doing so are too high. So if you have a neighborhood with 100 households attached to a DOCSIS node, you have 100 homes in contention for 38Mbps of bandwidth. IF you reach a point where all the users are using the network at the same time, your available bandwidth is shared and there will be congestion. Obviously. Congestion will be present. Now explain WHY its an issue if I can voluntarily increase my priority to bypass the congestion.
said by NetAdmin1:Translation of the DSCP tags still doesn't guarantee that the packet will receive the same priority in the next AS or three or four ASes down the line. Hell, one AS might not even have DSCP setup or may strip DSCP values. Great, I'm not trying to make DiffServ work in the internet. I know it does not currently. The bid-based packet scheme, which would require a new protocol that EVERY ISP would support, makes agreements in REAL-TIME. "I will pay you this much to transport this packet." Simple.
said by NetAdmin1:That is the thing, there is no money in it. Backbone provides have enough bandwidth that screwing around with DiffServ doesn't make sense. They have no shortage of bandwidth like some of the last mile providers. That's like saying there's no reason to board standby passengers on a plane because there is no money in it. If it is true, as you say, that the backbone providers NEVER have congestion, then there is no reason for them to pay attention to any priority based scheme. So they don't have to. This doesn't prevent others from using such a scheme.
said by NetAdmin1:So, basically, your scheme does nothing to fix the problems of network congestion and over-subscription, except to maybe boost the operators income... Boosting the operators income is one advantage. As I've been saying all along YOU DO NOT NEED TO PREVENT CONGESTION. A bid-based packet scheme just makes it so quality service can be provided even with congestion.
said by NetAdmin1: However, if everyone just pays the lowest rate possible for their packets, like they do for other things, then basically you see no improvement in cash flow. Very true. But in the face of congestion and lousy service, SOMEONE will pay more. That's the law of supply and demand.
said by NetAdmin1:Your scheme operates on far too many assumptions about the network and how users will pay. Economists have solved that for me. | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:Now explain WHY its an issue if I can voluntarily increase my priority to bypass the congestion. Because by allowing you to bypass the congestion, you increase the negative effects of the congestion on other users. Simple as that. Now people who are paying for service are not getting the level of service they should. You potentially create a greater level of dissatisfaction in the customers which will negatively impact the business's reputation and cash flow.
The bid-based packet scheme, which would require a new protocol that EVERY ISP would support, makes agreements in REAL-TIME. "I will pay you this much to transport this packet." Simple. In other words, you want to make the billing mechanisms of all providers more complicated. Additionally, your system will change billing from being fairly regular to varying wildly based on the per packet costs.
Businesses prefer regular costs over variable costs. There would have to be a HUGE net savings or HUGE profit to scrap the preference for predictable recurring costs.
Additionally, there is no way in hell that you are going to get EVERY ISP and all of the backbone providers to agree to your scheme. Go hang out on a network operations list or forum and you can see for yourself how divergent operations are at different providers.
Boosting the operators income is one advantage. As I've been saying all along YOU DO NOT NEED TO PREVENT CONGESTION. A bid-based packet scheme just makes it so quality service can be provided even with congestion. That depends on your definition of quality.
Very true. But in the face of congestion and lousy service, SOMEONE will pay more. That's the law of supply and demand. They get better service at the expense of others, other users who will leave one provider for a new provider. You also relegate those without the resources to having a crap experience because they can't afford to pay the QoS toll.
Economists have solved that for me. Economists are not network engineers and shouldn't be coming up with crazy schemes to problems they don't know anything about.
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:Because by allowing you to bypass the congestion, you increase the negative effects of the congestion on other users. Simple as that. Now people who are paying for service are not getting the level of service they should. You potentially create a greater level of dissatisfaction in the customers which will negatively impact the business's reputation and cash flow. First you need to define whatever "the level of service they should" is. People that don't pay market rate for service DON'T GET SERVICE. Simple as that.
I'm sick of AT&T's overages charges on my iPhone. Oh! That's why I DON'T HAVE an iPhone or a data plan from AT&T. Because I'm not willing to pay the cost. So what?
said by NetAdmin1:In other words, you want to make the billing mechanisms of all providers more complicated. Additionally, your system will change billing from being fairly regular to varying wildly based on the per packet costs. Correct.
said by NetAdmin1:Businesses prefer regular costs over variable costs. There would have to be a HUGE net savings or HUGE profit to scrap the preference for predictable recurring costs. There would be predictable trends, just as there are now.
said by NetAdmin1:Additionally, there is no way in hell that you are going to get EVERY ISP and all of the backbone providers to agree to your scheme. Go hang out on a network operations list or forum and you can see for yourself how divergent operations are at different providers. Hmmm. EVERY ISP is using IPv4. How did that happen?
said by NetAdmin1:That depends on your definition of quality. My definition of quality is lower latencies and fewer dropped packets. What's yours?
said by NetAdmin1:They get better service at the expense of others, other users who will leave one provider for a new provider. You also relegate those without the resources to having a crap experience because they can't afford to pay the QoS toll. Great! Now you understand. It is a toll. People that don't want to use a toll road can be stuck in traffic if they are too cheap to pay the toll.
said by NetAdmin1:Economists are not network engineers and shouldn't be coming up with crazy schemes to problems they don't know anything about. Economists solve problems related to scarce resources and human decision based on INCENTIVES. They know everything about it. | |
| | | | | | | | | | | | | | | | | | | |
1 edit | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:First you need to define whatever "the level of service they should" is. If Joe pays for 10Mbps, he should be able to get his 10Mbps. Little Jonny, who loves Bittorrent, should not be able to push Joe's speed into the crapper when he feels like paying for it.
If there is congestion, the only fair method to deal with it is for EVERYONE to be affected by it equally. What you are basically advocating is an oligarchical approach to deal with congestion, whereby those with money can rule the roost. Frankly, the egalitarian approach to the effects of congestion is more fair and sane.
There would be predictable trends, just as there are now. Not necessarily. The aggregate bandwidth utilization of a connection is pretty predictable, however, that doesn't translate to the scheme you are talking about. You said it yourself - the price people pay would be bid in real time, in other words, the costs and payments are constantly changing. People can change on the fly what they will and will not pay; likewise, because utilization rates change, the costs to the users will fluctuate. That constant fluctuation will make those trends very short lived and mostly useless.
Hmmm. EVERY ISP is using IPv4. How did that happen? They are using IP because they have to use it to be able to provide Internet access. Each ISP does not sit down and think about whether it should use IP (4 OR 6) or IPX or SNA... They use IP because there is no other option.
The proposed billing system is nothing like that.
My definition of quality is lower latencies and fewer dropped packets. What's yours? It varies based on application. Not everything requires low latency. Not every application requires 100% reliable packet delivery. Not every protocol requires the full 100Mps of connection I'm on now, much less that 10Mbps at my home.
Economists solve problems related to scarce resources and human decision based on INCENTIVES. They know everything about it. And they know nothing about networks, network engineering or any of the things that go into keeping large scale networks running efficiently and smoothly.
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:Frankly, the egalitarian approach to the effects of congestion is more fair and sane. Your opinion. I doubt the ISPs feel that way, especially since it doesn't maximize their profit.
said by NetAdmin1:They are using IP because they have to use it to be able to provide Internet access. Each ISP does not sit down and think about whether it should use IP (4 OR 6) or IPX or SNA... They use IP because there is no other option. The proposed billing system is nothing like that. No, that is exactly what I am proposing. A replacement network protocol that has billing built-in. And there are MANY other options for network protocols, but they all agreed to IPv4 at some point. It will CHANGE to IPv6 at some point.
said by NetAdmin1:It varies based on application. Not everything requires low latency. Not every application requires 100% reliable packet delivery. Not every protocol requires the full 100Mps of connection I'm on now, much less that 10Mbps at my home. And your point is?
said by NetAdmin1:And they know nothing about networks, network engineering or any of the things that go into keeping large scale networks running efficiently and smoothly. And that's why I, as a network engineer, have applied their proven theories to another domain. Obviously more research needs done. | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:Your opinion. I doubt the ISPs feel that way, especially since it doesn't maximize their profit. That's your opinion. Since ISPs are NOT jumping on the half cocked billing scheme you propose, it appears that they aren't in any hurry to try to profit off of congestion and instead are doing the more reasonable thing and upgrading the network.
No, that is exactly what I am proposing. A replacement network protocol that has billing built-in. And there are MANY other options for network protocols, but they all agreed to IPv4 at some point. It will CHANGE to IPv6 at some point. 1. IP was agreed upon before ISPs came into existence.
2. IP works well because it does one thing and does it well. Adding billing to it would result in protocol bloat. Billing features in IP would be reinventing the wheel because there are plenty of other billing methods that work fine.
said by NetAdmin1:It varies based on application. Not everything requires low latency. Not every application requires 100% reliable packet delivery. Not every protocol requires the full 100Mps of connection I'm on now, much less that 10Mbps at my home. And your point is?
And that's why I, as a network engineer, have applied their proven theories to another domain. Obviously more research needs done. If you are taking your network management practices from economics, you probably should do back to the technical manuals. You are taking your network management advice from the wrong people.
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:That's your opinion. Since ISPs are NOT jumping on the half cocked billing scheme you propose, it appears that they aren't in any hurry to try to profit off of congestion and instead are doing the more reasonable thing and upgrading the network. They're implementing metered billing. It's only a matter of time.
said by NetAdmin1:1. IP was agreed upon before ISPs came into existence. Wrong. »en.wikipedia.org/wiki/History_of···c_access
said by NetAdmin1:2. IP works well because it does one thing and does it well. Adding billing to it would result in protocol bloat. Billing features in IP would be reinventing the wheel because there are plenty of other billing methods that work fine. Network security is integrated into the design of the IPv6 architecture. Multicast is part of the base specification in IPv6 (optional in IPv4). ICMPv6 is required in all implementations of IPv6. Why would IPv6 have these requirements when there are plenty of other methods in IPv4 that work fine? Is IPv6 bloated? | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video Those BBSes and X.25 public access networks were not the Internet. They predated the Internet and by definition were not ISPs. From the article you linked to:
»en.wikipedia.org/wiki/History_of···Internet
The mandate was in order to connect to the Internet, one had to use IP. Network providers, like Compuserve, became ISPs once they connected their networks to the Internet, which mandated IP be used.
said by NetAdmin1:Network security is integrated into the design of the IPv6 architecture. Multicast is part of the base specification in IPv6 (optional in IPv4). ICMPv6 is required in all implementations of IPv6. Why would IPv6 have these requirements when there are plenty of other methods in IPv4 that work fine? Is IPv6 bloated? That's a poor argument for adding another extension to the protocol. Each of those items were added to the protocol because there is a sound technical reason for them to be integrated into IPv6 because each of those features can play a role in the actual process of delivering packets to their destination.
Your rationale for adding billing functions to IP is exactly what leads to protocol bloat. Billing features are NOT necessary to the delivery or smooth functioning of the network and don't belong in the protocol.
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:Those BBSes and X.25 public access networks were not the Internet. They predated the Internet and by definition were not ISPs. From the article you linked to: Great proof. They were not internet service providers because the internet didn't exist yet. Now you're just arguing semantics. They offered a networking and email service. Other networks did as well. They all had to AGREE to use IPv4 to create the internet, just as I said.
said by NetAdmin1:Each of those items were added to the protocol because there is a sound technical reason for them to be integrated into IPv6 because each of those features can play a role in the actual process of delivering packets to their destination. Security has nothing to do with the actual process of delivering packets. It is an additional service that doesn't need to be integrated into the network protocol. You said it yourself, you think it has to do one thing and do it well.
said by NetAdmin1:Your rationale for adding billing functions to IP is exactly what leads to protocol bloat. Billing features are NOT necessary to the delivery or smooth functioning of the network and don't belong in the protocol. So since the DSCP field is not used in the current internet, then that's protocol bloat as well? You claim it's not necessary for the smooth functioning of the network. Prioritization is NOT bloat. Having a different method of Prioritization is NOT bloat. Using pricing information for Prioritization is NOT bloat. | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:Great proof. They were not internet service providers because the internet didn't exist yet. Now you're just arguing semantics. They offered a networking and email service. Other networks did as well. They all had to AGREE to use IPv4 to create the internet, just as I said. Sometimes semantics need to be argued, especially when a term is misused. IP was mandated on the Internet, which Compuserve and its peers were not involved in building. Again, from your source of choise, Wikipedia:
"On January 1, 1983, TCP/IP protocols became the only approved protocol on the ARPANET, replacing the earlier NCP protocol."
"The networks based around the ARPANET were government funded and therefore restricted to noncommercial uses such as research; unrelated commercial use was strictly forbidden. This initially restricted connections to military sites and universities. During the 1980s, the connections expanded to more educational institutions, and even to a growing number of companies such as Digital Equipment Corporation and Hewlett-Packard, which were participating in research projects or providing services to those who were."
To get connected to that network, there was no negotiation on the part of the various companies, they either used IP or they didn't connect. There was no agreement - to connect to the Internet, they were compelled to use IP.
It is the same buying a gasoline powered car, I don't agree to fuel my car with gasoline, I have to use gasoline for the car to run. If I decide to fuel my car with diesel, the car won't run properly.
Security has nothing to do with the actual process of delivering packets. It is an additional service that doesn't need to be integrated into the network protocol. You said it yourself, you think it has to do one thing and do it well. I, and others, would argue that having the tools to maintain data security and integrity are key parts of delivering packets. I can't trust all the networks between my host and the host I am communicating with. IPSEC was developed to address those issues with IPv4, a protocol designed on the assumption that you could trust everyone on the network. Now that we know that isn't a case, a method of securing data in transit needed to exist.
So since the DSCP field is not used in the current internet, then that's protocol bloat as well? You claim it's not necessary for the smooth functioning of the network. Boy are you off base. In the course of this discussion, it has never been said that DSCP is either bloat or unnecessary. What I have said and you blithely dismissed because of your agenda is that using DSCP has issues when used BETWEEN ASes. Intra-AS, DSCP is not an issue. You aren't going to get every provider on the same page, classifying traffic the same way or honor another providers class priorities, especially competitors.
Using pricing information for Prioritization is NOT bloat.
Developing all sorts of crazy protocols and extensions to IP is bloat. You are the one who advocated we create all sorts of protocols and mechanisms to do all this craziness. You are the one that wants to fundamentally change the way that networks and equipments deal with congestion in a wild, half cock and untested method. You argue for per packet pricing without laying specifics on how we would establish baseline prices for packets.
In other words, your position presents far more questions and unknowns that the current way things work.
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video Great so I was "wrong" that everybody agreed to use IPv4. They were "forced." In any case the internet will move to IPv6, and in the future it can move to something different.
said by NetAdmin1:I, and others, would argue that having the tools to maintain data security and integrity are key parts of delivering packets. I can't trust all the networks between my host and the host I am communicating with. IPSEC was developed to address those issues with IPv4, a protocol designed on the assumption that you could trust everyone on the network. First of all IPSEC was developed for IPv6 and BACKPORTED to IPv4. And transport layer security is what most everyone uses, so why does security have to be in the network protocol again?
said by NetAdmin1:Developing all sorts of crazy protocols and extensions to IP is bloat. You are the one who advocated we create all sorts of protocols and mechanisms to do all this craziness. I only advocated for ONE network protocol or ONE extension, not "all sorts of protocols". There are a lot crazier RFCs that are much more bloated than a simple price-based prioritization would be. | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:Great so I was "wrong" that everybody agreed to use IPv4. They were "forced." In any case the internet will move to IPv6, and in the future it can move to something different. Well, if you have no other choice but IP to use, that would be a forced choice.
said by the dictionary :
tr.v., forced, forc·ing, forc·es.
1. To compel through pressure or necessity:
It seems the term forced, as in compelled through necessity, would fit the description.
First of all IPSEC was developed for IPv6 and BACKPORTED to IPv4. And transport layer security is what most everyone uses, so why does security have to be in the network protocol again? First, your point? The statement that "IPSEC was developed to address those issues with IPv4" covers the fact that IPSEC was develop for IPv6. Obviously those involved in creating IPv6 realized that the security issues of IPv4 needed to be addressed.
Second, ever think that transport level security came about due to the lack of security at the network layer?
said by »74.125.93.132/search?q=cache:5HB···fox-a#18 :
History of SSL
Netscape developed The Secure Sockets Layer Protocol (SSL) in 1994, as a response to the growing
concern over security on the Internet. SSL was originally developed for securing web browser and server
communications. The specification was designed in such a way so you can enable other applications,
such as TELNET and FTP, to use SSL.
In other words, transport layer security was a result of IPv4 lacking security features.
I only advocated for ONE network protocol or ONE extension, not "all sorts of protocols". Ok, fine, you are right if you want to nitpick... You advocated only ONE protocol and one extension. However, you still haven't proven that such a system is (a) needed or (b) will make things better without creating issues or (c) that it is better than current systems (average bandwidth billing, 95th percentile billing, etc.)
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1:Second, ever think that transport level security came about due to the lack of security at the network layer? How about the lack of any security whatsoever. You still haven't explained why it's needed at the network layer.
Same reason you can't understand why billing at the network layer would be better. | |
| | | | | | | | | |
1 edit | Re: Metered billing coming - for telcos & cable; reason video said by anderboy:How about the lack of any security whatsoever. You still haven't explained why it's needed at the network layer. In this case, I'll defer. If you want the answer, you probably would be better asking those involved in making that decision. I see the advantages, but apparently you don't and frankly I don't care.
Same reason you can't understand why billing at the network layer would be better. Better than what, polling interfaces for amount of data that actually transits the network? No, your crazy scheme makes more sense than tracking the actual number of bits hitting our interfaces. Riiiiiiight...
--
Kilroy was here | |
| | | | | | | | | | | | Re: Metered billing coming - for telcos & cable; reason video said by NetAdmin1: I see the advantages, but apparently you don't and frankly I don't care. Well then. Same to you. | |
|
| |
|
