As many posters have pointed out, there are about a gajillion ways to do this (I'm a big fan of GRE, Quagga, and some judicious OSPF metrics:)
If you're talking about remote offices with workers who aren't IT-aware past "Oooooh, email" and you start adding layers of complexity to their Internet connection(s), you necessarily increase the risks of network downtime due to configuration errors, busted hardware, code bugs, etc... many times things you can't fix remotely. Some assessment of your target customer's tech-level for dealing with those issues should go in to the design decision. E.g. - implementing a Linux-based firewall on repurposed commodity hardware in an office without full time IT staff might make for a nightmare if the hard drive died; you likely would end up driving to that office to fix it, hiring a local "consultant" to assist if you can't drive there reasonably, or re-tasking someone's time in the office for your own nefarious IT purposes (instead of them being out there selling your employer's bread and butter).
If you're a centralized network manager at the company HQ, then the conversation that starts with "Powercycle the blue-and-white box and tell me what the LED's do" is a lot easier to deal with than "What does the screen say? Oh, well a kernel panic means something really bad happened..." You can mitigate those issues, but you'll inevitably end up on the phone someday with an office worker whose "Internet ain't workin". Sometimes it's easier to spend the money up front for a piece of dedicated hardware, rather than in the back-end on support costs (opportunity or actual).
If you liked either Bad Taste or Dead Alive, try out "Meet the Feebles", also from Peter Jackson. Possibly one of the most creepily disturbing movies ever made with an entirely puppet cast.
At a previous employer, I ran BB from a Linux machine to monitor a pretty diverse set of boxes (Irix, FreeBSD, Win2k, WinNT4, AS400, Cisco 2500 and 7500 series, etc...) One of the best parts about BB is it's extensibility; any kind of shell script can be implemented as an monitor/alarm generator for BB, making it *extremely* nimble.
Securing the installation is easy enough, if you're not a numnuts.
I work in a company with 4 locations, two on the West Coast, one in the Rockies, and one on the East Coast. I send/receive on the order of 300 IM's per day, discussing any topic from customer issues to what I had for dinner last night. I have resolved at least 4 customer issues today alone utilizing *only* IM; another employee has the customer on the phone and I am able to work with the employee to determine the issue and resolve it remotely *without having to get directly involved via phone*. That's it, the customer's issue is resolved and they are happy; both I and my co-worker can get back to work (immediately) knowing that our customer is satisified. And it didn't take an email, a trouble ticket, or 4-24 hours to get completed (these are regular process for dealing with issues that technicians can't personally resolve immediately).
While not *all* of my IM's are work-related in the strictest sense, about 85% of my traffic is directly related to my work directives. And the rest saves me from having to walk over/drive over/call over to speak with people who I would normally shoot the proverbial "bull" with anyway.
Unproductive? I think you're eating too many paint chips.
Perhaps this is one of the benefits of "enterprise-class" IM software? The ability to "tier" the support organization. I.e. - Tier 1 support can only IM to other Tier 1 agents, with the exception of the "senior" tech staff, who can get to Tier 2. The systematic streamlining of support requests could be implemented using some im.allow/im.deny type functionality (preferably at the server level, so I can still yell at the lower tier guys if i want to:) ).
I have the same issue at my employer; 80 times per day, I get quick "can you help me" type messages. There are these things called "Away Messages" tho that seem to work really well.
Can you please explain to me how line-shared ADSL service can ever be sold to a CLEC at "below cost"?
By definition:
1) The CLEC provider must collocate their own equipment with the ILEC/Bell/Evil Empire; therefore, the CLEC must pay recurrring collocation fees, a one time "setup fee", and additional application-for-space fees to the ILEC (and that shit ain't cheap!!! $5000 just to apply; multiply that by 2,000 offices!!!) These fees are in addition to purchasing the equipment in the first place (DSLAM's, ATM switches, and DS3 multiplexors are not small or cheap), hiring/paying their own technicians to install/maintain it (technicians that can't access that equipment without jumping through "building access authorization" hoops), and paying for support contracts with the vendors of that equipment (ever bought a Cisco support contract? that ain't cheap either.)
2) The line-shared service must be provisioned over a line with existing POTS service; this means that the loop/pair/last mile was ALREADY delivered to the end user's premises and the end user is ALREADY paying the ILEC for their POTS service (note that POTS service recurring revenue is supposed to pay for any premises dispatches by ILEC technicians for loop quality issues related to voice services)
3) The CLEC still has to PAY the ILEC to connect the DSL equipment (which they ALREADY pay to keep in the ILEC office) to the end user's phone line (for which the end user is paying already)
4) The ILEC charges a monthly fee to the CLEC for providing a simple set of equipment cross connects in the Central Office; remember that this is over and above what the end user is already paying them for POTS service
5) UNE DSL lines are not cheap either, but CLEC's still pay more then end user's for the "privilege" to lease a dry copper pair. Most ILEC's will lease an "alarm pair" for under $20 month to an end user; many CLEC's pay nearly twice that for a pair with nothing on it!!!
Forgive me for saying "below cost my ass!!!" If the Bell monopolies weren't so uber-bloated w/r/t their business practices, human resources, logistics, etc..., perhaps they'd be making money hand over fist instead of bitching about not having any money or incentive to buildout in rural areas or extend buildout further into urban/suburban areas. I wish I could get the government to subsidize my business; then I could screw my customers every which way I could think of in order to lure shareholders in to giving me even more money.
the advantages here seem to be mostly financial and logistical.
by putting the DSLAM in a barn in the community, not only does the community save money (by not having to collocate with Qwest, not a cheap prospect), but they don't have to deal with the nightmare of accessing their own damn equipment in the CO.
You say that your employer is an ISP with a collocated DSLAM? Have you ever tried to access a Qwest CO? Or even attempted to get authorized to access a Qwest CO? (they are individual issues, you know; having permission to have access and actually getting access are 2 very different things)
I noted in the FAQ that there is mention of the fact that the service is billed on a quarterly basis (rather than monthly) for ease of administration.
Being an employee of one of the few DSL DLEC's left out there in RBOC-space (due to the fact that partner ISP's/wholesale purchasers tended to burst along with the hideously over-eschewed dotcom bubble), this is an issue that hits very close to home for me:
Do you anticipate, or have any contingencies for, a time when the co-op will not be able to meet it's financial obligations to it's various providers?
Obviously, size does matter in this case, but this is still a valid question. What if 20 (half of the reported number of) homes in Ruby Ranch are destroyed in one of the Colorado "super-fires", for example? Can the co-op continue to maintain network equipment and availability at half revenue (assuming that some portion of the 20 homes constitutes half the subscriber base)?
the problem here is not the technological limitation of providing the equipment or service on the subscriber side.
the largest issue with providing VoIP services (or even VoDSL service) is delivering the aggregated voice traffic to some 3rd party (or to Qwest, if you're a sadist) to provide Class 5/SS7 switching in to the PSTN.
it wouldn't really make sense to do this unless the co-op itself became some kind of voice CLEC, in which case they would need to provide a significantly higher guarantee of service (there's that whole 911 liability thing) and would hence require a seriously higher set of operating costs
from this page:
What line speeds do subscribers get? Do they get a dedicated IP address? Can they operate servers?
These are all difficult questions. Ours is a coop, meaning that every cost we incur must necessarily come sooner or later out of the pockets of the subscribers. We are charged by our upstream provider according to our traffic levels. If a subscriber were to generate so much traffic that we had to pay an extra $250 per month to our provider, we would need to charge that $250 to that subscriber. There would be no other choice.
At first, we are going to throttle most of our subscriber connections down to 206K bps. Later, after we accumulate some experience and see what our traffic levels really turn out to be, we will consider raising the connection speeds.
mod parent up. best solution is to make everyone pay the same rates to the same single company.
the only problem is telling the ILEC's that they no longer own all of their own switching equipment, remote huts, transmission equipment, etc...
the wholesaler would have to have MEGAbucks in order to pull that off. or it would have to be a governmental institution that could affordably compensate the ILEC's for the taking by "eminent domain" of their equipment.
if the wholesaler was a non-profit organization (aka government agency), there wouldn't be any issues with competitive pricing, because everyone would be paying the same rates; the only way to differentiate yourself from the rest of the crowd would be by offering better service (something we all sorely need anyway).
what are the economic implications of that statement?
if your telco's network is disconnected from your premises under the auspices of "running your own wire", you have to set up your own telco network.
can you imagine what it would cost for me to buy the switching equipment and lay the copper just to call my buddy across town?
how bout if i want to call my mom at home in another state? i have to long haul the switch i set up to call my buddy to the state my mom lives in, setup switching equipment there as well, and then lay copper from that switch to her premises.
these issues are all compounded when you start to talk about data connectivity. establishing your own backbone connectivity to the internet is not a cheap thing to do. now imagine deploying the access technologies required to provide even the connection to the home (DSLAM or CMTS, choose your weapon) plus the backend connectivity required to connect that equipment to the internet backbone router.
there is no way that any smart, private entrepeneur (unless you're bill gates) would be able to lay out that much cash to build out that kind of network.
the issue on the regional end is that you have no access to the networks of other regions unless you are connected to the other regions. for internet connectivity, this is not an issue (what with the wonders of BGP); for telephone exchange, that means you can't call anyone in the other region (unless of course someone builds the pristine yet phantom long distance network that was previously described).
Why should government dictate what the owner of that wire has to do with it? Allowing other DSL providers to use that infrastructure is going to cost the Bells money.
the problem with this statement is that the Bells make money off of "others" (Covad, DSL.net, etc...) that use their infrastructure. the government is required to step in and say "you must allow these guys to use your "last mile". the Bells don't like that because (at least some of the time) their little competitors can offer higher quality service (in terms of customer care, mean time to repair, etc...) to their customers; this makes the Bells look bad, since the little guys are doing this using the Bells' own network (at least at the physical layer)
Who says that there haven't been 4 gens of previous failures in this "experimental programme"? Since when did any kind of privately funded R&D project make it's findings public without being successful? That sounds like a recipe for tumbling stock prices to me...
If there is already a DNS root in place, why not visualize setting up a central object database at the specific site? I.E. cod.slashdot.org/whatever.object.you.want. that way, each individual site would administer it's own object database. this would eliminate the need for standardizing the server systems and would take the power away from a central authority(that could possibly screw it up...)
That's the entire point of them appointing a chief technologist. The government (in case you hadn't noticed) has a history of poking their nose in where they don't belong. That's not something that Dave Farber can help. What he can do is help educate the technologically illiterate (read : luser) upper powermongers that are given control over something they shouldn't even touch in the first place. His appointment may not be curing the "disease", but it will certainly help alleviate some of the symptoms.
Slashdot Mirror
As many posters have pointed out, there are about a gajillion ways to do this (I'm a big fan of GRE, Quagga, and some judicious OSPF metrics :)
If you're talking about remote offices with workers who aren't IT-aware past "Oooooh, email" and you start adding layers of complexity to their Internet connection(s), you necessarily increase the risks of network downtime due to configuration errors, busted hardware, code bugs, etc... many times things you can't fix remotely. Some assessment of your target customer's tech-level for dealing with those issues should go in to the design decision. E.g. - implementing a Linux-based firewall on repurposed commodity hardware in an office without full time IT staff might make for a nightmare if the hard drive died; you likely would end up driving to that office to fix it, hiring a local "consultant" to assist if you can't drive there reasonably, or re-tasking someone's time in the office for your own nefarious IT purposes (instead of them being out there selling your employer's bread and butter).
If you're a centralized network manager at the company HQ, then the conversation that starts with "Powercycle the blue-and-white box and tell me what the LED's do" is a lot easier to deal with than "What does the screen say? Oh, well a kernel panic means something really bad happened..." You can mitigate those issues, but you'll inevitably end up on the phone someday with an office worker whose "Internet ain't workin". Sometimes it's easier to spend the money up front for a piece of dedicated hardware, rather than in the back-end on support costs (opportunity or actual).
I almost wish the score went lower than -1.
If you liked either Bad Taste or Dead Alive, try out "Meet the Feebles", also from Peter Jackson. Possibly one of the most creepily disturbing movies ever made with an entirely puppet cast.
Thanks to the parent.
At a previous employer, I ran BB from a Linux machine to monitor a pretty diverse set of boxes (Irix, FreeBSD, Win2k, WinNT4, AS400, Cisco 2500 and 7500 series, etc...) One of the best parts about BB is it's extensibility; any kind of shell script can be implemented as an monitor/alarm generator for BB, making it *extremely* nimble.
Securing the installation is easy enough, if you're not a numnuts.
at least the subject worked on this reply :)
I work in a company with 4 locations, two on the West Coast, one in the Rockies, and one on the East Coast. I send/receive on the order of 300 IM's per day, discussing any topic from customer issues to what I had for dinner last night. I have resolved at least 4 customer issues today alone utilizing *only* IM; another employee has the customer on the phone and I am able to work with the employee to determine the issue and resolve it remotely *without having to get directly involved via phone*. That's it, the customer's issue is resolved and they are happy; both I and my co-worker can get back to work (immediately) knowing that our customer is satisified.
And it didn't take an email, a trouble ticket, or 4-24 hours to get completed (these are regular process for dealing with issues that technicians can't personally resolve immediately).
While not *all* of my IM's are work-related in the strictest sense, about 85% of my traffic is directly related to my work directives. And the rest saves me from having to walk over/drive over/call over to speak with people who I would normally shoot the proverbial "bull" with anyway.
Unproductive? I think you're eating too many paint chips.
Perhaps this is one of the benefits of "enterprise-class" IM software? The ability to "tier" the support organization. I.e. - Tier 1 support can only IM to other Tier 1 agents, with the exception of the "senior" tech staff, who can get to Tier 2. The systematic streamlining of support requests could be implemented using some im.allow/im.deny type functionality (preferably at the server level, so I can still yell at the lower tier guys if i want to:) ).
I have the same issue at my employer; 80 times per day, I get quick "can you help me" type messages. There are these things called "Away Messages" tho that seem to work really well.
just a thought:
a bleshere=inserttheirvalues
/. semantics...)
are you using the m$ internet exploder? is it (or whatever browser) caching some form data for you?
since the base url is always http://slashdot.org/comments.pl?insertvariousvari
doesn't autocomplete always want to put something in there, if it's turned on?
(as an aside: is something offtopic if it's in reply to a parent that's already offtopic? just questioning my
By definition:
1) The CLEC provider must collocate their own equipment with the ILEC/Bell/Evil Empire; therefore, the CLEC must pay recurrring collocation fees, a one time "setup fee", and additional application-for-space fees to the ILEC (and that shit ain't cheap!!! $5000 just to apply; multiply that by 2,000 offices!!!)
These fees are in addition to purchasing the equipment in the first place (DSLAM's, ATM switches, and DS3 multiplexors are not small or cheap), hiring/paying their own technicians to install/maintain it (technicians that can't access that equipment without jumping through "building access authorization" hoops), and paying for support contracts with the vendors of that equipment (ever bought a Cisco support contract? that ain't cheap either.)
2) The line-shared service must be provisioned over a line with existing POTS service; this means that the loop/pair/last mile was ALREADY delivered to the end user's premises and the end user is ALREADY paying the ILEC for their POTS service (note that POTS service recurring revenue is supposed to pay for any premises dispatches by ILEC technicians for loop quality issues related to voice services)
3) The CLEC still has to PAY the ILEC to connect the DSL equipment (which they ALREADY pay to keep in the ILEC office) to the end user's phone line (for which the end user is paying already)
4) The ILEC charges a monthly fee to the CLEC for providing a simple set of equipment cross connects in the Central Office; remember that this is over and above what the end user is already paying them for POTS service
5) UNE DSL lines are not cheap either, but CLEC's still pay more then end user's for the "privilege" to lease a dry copper pair. Most ILEC's will lease an "alarm pair" for under $20 month to an end user; many CLEC's pay nearly twice that for a pair with nothing on it!!!
Forgive me for saying "below cost my ass!!!" If the Bell monopolies weren't so uber-bloated w/r/t their business practices, human resources, logistics, etc..., perhaps they'd be making money hand over fist instead of bitching about not having any money or incentive to buildout in rural areas or extend buildout further into urban/suburban areas. I wish I could get the government to subsidize my business; then I could screw my customers every which way I could think of in order to lure shareholders in to giving me even more money.
is votation really a word?
strange...
the advantages here seem to be mostly financial and logistical.
by putting the DSLAM in a barn in the community, not only does the community save money (by not having to collocate with Qwest, not a cheap prospect), but they don't have to deal with the nightmare of accessing their own damn equipment in the CO.
You say that your employer is an ISP with a collocated DSLAM? Have you ever tried to access a Qwest CO? Or even attempted to get authorized to access a Qwest CO? (they are individual issues, you know; having permission to have access and actually getting access are 2 very different things)
I noted in the FAQ that there is mention of the fact that the service is billed on a quarterly basis (rather than monthly) for ease of administration.
Being an employee of one of the few DSL DLEC's left out there in RBOC-space (due to the fact that partner ISP's/wholesale purchasers tended to burst along with the hideously over-eschewed dotcom bubble), this is an issue that hits very close to home for me:
Do you anticipate, or have any contingencies for, a time when the co-op will not be able to meet it's financial obligations to it's various providers?
Obviously, size does matter in this case, but this is still a valid question. What if 20 (half of the reported number of) homes in Ruby Ranch are destroyed in one of the Colorado "super-fires", for example? Can the co-op continue to maintain network equipment and availability at half revenue (assuming that some portion of the 20 homes constitutes half the subscriber base)?
the problem here is not the technological limitation of providing the equipment or service on the subscriber side.
the largest issue with providing VoIP services (or even VoDSL service) is delivering the aggregated voice traffic to some 3rd party (or to Qwest, if you're a sadist) to provide Class 5/SS7 switching in to the PSTN.
it wouldn't really make sense to do this unless the co-op itself became some kind of voice CLEC, in which case they would need to provide a significantly higher guarantee of service (there's that whole 911 liability thing) and would hence require a seriously higher set of operating costs
These are all difficult questions. Ours is a coop, meaning that every cost we incur must necessarily come sooner or later out of the pockets of the subscribers. We are charged by our upstream provider according to our traffic levels. If a subscriber were to generate so much traffic that we had to pay an extra $250 per month to our provider, we would need to charge that $250 to that subscriber. There would be no other choice.
At first, we are going to throttle most of our subscriber connections down to 206K bps. Later, after we accumulate some experience and see what our traffic levels really turn out to be, we will consider raising the connection speeds.
what is the actual probability that your bell would pull the competitive access from ISP?
that would make them a most unpopular company in the media.
plus they would lose all revenue from the circuits (physical medium still has to be leased) that your isp is giving them.
mod parent up.
best solution is to make everyone pay the same rates to the same single company.
the only problem is telling the ILEC's that they no longer own all of their own switching equipment, remote huts, transmission equipment, etc...
the wholesaler would have to have MEGAbucks in order to pull that off. or it would have to be a governmental institution that could affordably compensate the ILEC's for the taking by "eminent domain" of their equipment.
if the wholesaler was a non-profit organization (aka government agency), there wouldn't be any issues with competitive pricing, because everyone would be paying the same rates; the only way to differentiate yourself from the rest of the crowd would be by offering better service (something we all sorely need anyway).
what are the economic implications of that statement?
if your telco's network is disconnected from your premises under the auspices of "running your own wire", you have to set up your own telco network.
can you imagine what it would cost for me to buy the switching equipment and lay the copper just to call my buddy across town?
how bout if i want to call my mom at home in another state? i have to long haul the switch i set up to call my buddy to the state my mom lives in, setup switching equipment there as well, and then lay copper from that switch to her premises.
these issues are all compounded when you start to talk about data connectivity. establishing your own backbone connectivity to the internet is not a cheap thing to do. now imagine deploying the access technologies required to provide even the connection to the home (DSLAM or CMTS, choose your weapon) plus the backend connectivity required to connect that equipment to the internet backbone router.
there is no way that any smart, private entrepeneur (unless you're bill gates) would be able to lay out that much cash to build out that kind of network.
the issue on the regional end is that you have no access to the networks of other regions unless you are connected to the other regions. for internet connectivity, this is not an issue (what with the wonders of BGP); for telephone exchange, that means you can't call anyone in the other region (unless of course someone builds the pristine yet phantom long distance network that was previously described).
Why should government dictate what the owner of that wire has to do with it? Allowing other DSL providers to use that infrastructure is going to cost the Bells money.
the problem with this statement is that the Bells make money off of "others" (Covad, DSL.net, etc...) that use their infrastructure. the government is required to step in and say "you must allow these guys to use your "last mile". the Bells don't like that because (at least some of the time) their little competitors can offer higher quality service (in terms of customer care, mean time to repair, etc...) to their customers; this makes the Bells look bad, since the little guys are doing this using the Bells' own network (at least at the physical layer)
To be able to install and run such simulation on your PC, we recommend the following minimum system specifications:
-
Operating System: Windows 95, Windows 98, Windows ME, Windows 2000
Professional, or Windows NT 4.0
-
Processor: Athlon, PII, PIII, PIV
-
Speed: Min 450MHz. Preferably 700+
-
Memory: Min 128 MB at this stage. (64MB may be enough but we havn't
tested) for use
----- Yep, there you have it...the only time i'm waiting is if i already bought the software and i need techie help
if i don't need technical ass-istance from you and/or your site, i'm going somewhere else if you make me wait
Who says that there haven't been 4 gens of previous failures in this "experimental programme"? Since when did any kind of privately funded R&D project make it's findings public without being successful? That sounds like a recipe for tumbling stock prices to me...
it was going to happen here (the good old U S of A).
;)
What's next?
"My family has a history of heart disease, doc. Can you fix it? You know, for kids..."
"My family has a history of obesity, doc. Can you fix it? You know, for kids..."
"My family has a history of being ugly, doc. Can you fix it? You know, for kids..."
I guess everything will be alright, since without federal funding, all scientific experimentation will fail utterly anyway.
If there is already a DNS root in place, why not visualize setting up a central object database at the specific site? I.E. cod.slashdot.org/whatever.object.you.want. that way, each individual site would administer it's own object database. this would eliminate the need for standardizing the server systems and would take the power away from a central authority(that could possibly screw it up...)
That's the entire point of them appointing a chief technologist. The government (in case you hadn't noticed) has a history of poking their nose in where they don't belong. That's not something that Dave Farber can help. What he can do is help educate the technologically illiterate (read : luser) upper powermongers that are given control over something they shouldn't even touch in the first place. His appointment may not be curing the "disease", but it will certainly help alleviate some of the symptoms.
you know, when you log in, you can customize the page so you don't have to read reviews. anonymous wienie!!