nanog mailing list archives
RE: ip-precedence for management traffic
From: "TJ" <trejrco () gmail com>
Date: Tue, 29 Dec 2009 12:18:24 -0500
-----Original Message----- From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs () verizon com] Sent: Tuesday, December 29, 2009 11:43 To: Joe Greco Cc: NANOG list Subject: RE: ip-precedence for management traffic Joe wrote:Getting back to the OP's message, I keep having these visions of the castrated "Internet" access some hotels provide. You know the ones. The ones where everything goes through a Web proxy and you're forced to have IE6 as a browser. For some people, who just want to log on to Yahoo or Hotmail or whatever to check their e-mail, that's fine. However, some of us might want to be able to VNC somewhere, or do VoIP, or run a VPN connection... these are all well-known Internet capabilities, and yet some providers of so-called "Internet" access at hotels haven't allowed for them. Do we really want to spread that sort of model to the rest of the Internet? All it really encourages is for more and more things to be ported to HTTP, including, amusingly, management of devices... at which point we have not really solved the problem but we have succeeded at doing damage to the potential of the Internet.Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a
one-
size-fits-all model like the hotels try to do. Imagine a residential ISP
that
offers castration at a lower price point than what is currently charged
for
monthly "raw" access. I think that many consumers would opt for that
choice,
while those who need access to everything would continue to pay the same
rate.
The price drop would be the incentive to get castrated, and what you give
up
would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos- blocking, etc. in addition to mitigating attacks against the mechanisms
from
hijacked residential computers. Marc
My $.02 or so - This "widespread castration" would force application developers to jump through the same NAT-traversal hoops all over again, adding more code-bloat / operational overhead and stifling innovation. Naturally, once created, this lower-class of internet user would probably become the "norm" and force a race to the bottom in terms of capabilities and performance (or perhaps, another "arms race" between the proxy implementations and the proxy avoidance implementations) ... rinse-repeat-fail_to_learn, all over again. /TJ PS - could we choose a different term; "cut-rate castration" brings unpleasant medical-accidents to mind ...
Current thread:
- Re: ip-precedence for management traffic, (continued)
- Re: ip-precedence for management traffic tvest (Dec 29)
- Re: ip-precedence for management traffic Randy Bush (Dec 29)
- Re: ip-precedence for management traffic Christopher Morrow (Dec 29)
- Re: ip-precedence for management traffic Randy Bush (Dec 29)
- Re: ip-precedence for management traffic tvest (Dec 29)
- Re: ip-precedence for management traffic Alexander Harrowell (Dec 30)
- Re: ip-precedence for management traffic Joe Greco (Dec 29)
- RE: ip-precedence for management traffic Sachs, Marcus Hans (Marc) (Dec 29)
- Re: ip-precedence for management traffic Joe Greco (Dec 29)
- Re: ip-precedence for management traffic Nick Hilliard (Dec 29)
- RE: ip-precedence for management traffic TJ (Dec 29)
- Re: ip-precedence for management traffic Joe Greco (Dec 29)
- Re: ip-precedence for management traffic Jared Mauch (Dec 29)
- Re: ip-precedence for management traffic Andy Davidson (Dec 29)
- Re: ip-precedence for management traffic Joe Provo (Dec 30)
- RE: ip-precedence for management traffic Tomas L. Byrnes (Dec 29)
- Re: ip-precedence for management traffic David Conrad (Dec 29)
- Re: ip-precedence for management traffic Randy Bush (Dec 29)
- Re: ip-precedence for management traffic Michael Thomas (Dec 29)
- Re: ip-precedence for management traffic Jared Mauch (Dec 29)
