Thanks for the clarification, Martin, I appreciate it. I've been
primarily looking at the "intractable residential gateway" problem from
the standpoint of ALTO, but I can see it's an issue for GEOPRIV as well,
and it's also one for DNSSEC as virtually all RG's are out of compliance
with the DNSSEC requirements. The obsolete RG issue crops up over and
over in IETF, it's the primary reason the Internet doesn't have
widespread deployment of ECN right now. Perhaps there needs to be a
working group on slapping RG vendors upside the head until they behave
properly.
In the ALTO case, there does seem to be a fairly strong connection
between the service provider for ALTO and the RG provider, but in the
case of other services this isn't the case. One way forward in the face
of this dilemma is for someone to make the necessary enhancements to
DHCP, DNS, or whatever to support the new protocol/feature and release
that into the Linux world. The one thing we have working for us here is
the fact that these devices all run open source Linux, even if they're
not all at the same level (2.4 kernels vs. 2.6)
Thanks again,
RB
Thomson, Martin wrote:
Hi Richard,
I am aware of the scenarios where the ISP effectively owns and manages the residential gateway. These are the cases where this problem is easily solved. However, in my (admittedly limited) experience in this matter, these cases are
I’ll concede that the draft doesn’t duly acknowledge this reality, and it
should. But that issue was not the primary concern in the draft.
There are two cases that remain interesting:
- I live in a country (Australia) where it is rare for an ISP to own and operate CPE.
- Even as newer Broadband Forum specifications are implemented and deployed, there are a large number of areas operating on old specifications. I know of many people who are still getting 256k/512k/1.5mbps on old equipment. In many cases, this equipment is adequate for their needs even though it is long beyond the end of its support period.
This statement is entirely incorrect:
Unlike location services, ALTO is a service that's seen as tightly-coupled with
an ISP's infrastructure.
Location *services* might not have any binding to access network infrastructure, if you are thinking of navigation or where is the nearest X type of service. That's not what GEOPRIV is developing. GEOPRIV protocols are about talking to a server that has an understanding of network topology as well as it's relationship to the physical world so that it can provide the device with location information.
By that token, the discovery problem in GEOPRIV the same as ALTO.
I hope that clears up any misunderstanding,
--Martin
---
From: Richard Bennett [mailto:[email protected]]
Sent: Friday, 27 March 2009 11:16 AM
To: Thomson, Martin
Cc: Matt Lepinski; [email protected]; Winterbottom, James
Subject: Re: [alto] ALTO Discovery and draft-ietf-geopriv-lis-discovery
My primary employer is a provider of residential gateways to major ISPs, and I find that this document doesn't reflect my experience. Let me explain. North American telco ISPs supply a residential gateway to their customers as part of their Internet access (or triple-play) service. This goes for AT&T, Verizon, and Qwest. Some cable MSOs do as well, but the larger cable MSOs (Comcast and Time-Warner.)
The telco RGs support the DSL Forum's TR069 protocol, which permits the operator to push firmware updates into these devices, change configurations, and and run diagnostics. These ISPs see the RG as a part of their network infrastructure. It's perfectly practical for the telco ISPs to update the firmware in their TR069-controlled RG's to support a new feature in the ISP's network such as the ALTO route selector. And in fact, the specific mechanisms that rely on vendor-defined options in the DHCP payload are similar to features in use today to support some IPTV functions. TR069-controlled RGs probably make up something like 30-40% of the market in the US today; I can't comment on the situation in other countries.
To the extent that RGs should be seen as intractable obstacles to new protocols and services, the culprits are the devices sold through the retail channel that aren't ISP-controllable. These devices raise a number of interesting problems for the deployment of services that enhance and extend such things as DSCP markings, DNS, and DHCP payloads, and in fact simply for faster Internet connections. Upgrade your Comcast connection to the new DOCSIS 3.0 service and you may find your old RG can't keep up. Hence, the cable MSO user community is already in a position where some features are not available to them if their RG is below par.
Unlike location services, ALTO is a service that's seen as tightly-coupled with
an ISP's infrastructure. Hence, it's reasonable to assume that ISPs who wish to
offer this service will be in a position to either: A) upgrade the relevant RGs
to support it; or B) Tell the customer how to upgrade his RG to support it.
The software for the retail RGs tends to come from a limited number of sources,
so adding a new feature isn't as hard as it may appear. Ultimately, almost all
of this stuff is based on Busybox Linux.
I hope this helps.
RB
Thomson, Martin wrote:
I also wanted to point out that there is what I believe to be a reasonably good problem statement regarding the problem as it relates to residential gateways in the document:
http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery
There is also some discussion in the document on solutions, but I wouldn't dwell on those overmuch.
--Martin
-----Original Message-----
From: Matt Lepinski [mailto:[email protected]]
Sent: Thursday, 26 March 2009 3:03 PM
To: [email protected]
Cc: Thomson, Martin; Winterbottom, James
Subject: ALTO Discovery and draft-ietf-geopriv-lis-discovery
Just wanted to quickly re-iterate a point that Martin Thomson had made
during today's ALTO meeting.
GEOPRIV has been working (for well over a year) on the following
problem:
"How does a device locate a server providing a given service that is
topologically close (in a network topology sense) to the device"
In the case of GEOPRIV, the service in question is a 'Location
Information Server (LIS)', but a believe that the problem of
discovering
a "local" (in a network topology sense) alto server has many similar
challenges as the GEOPRIV discovery problem.
Based on my experience in GEOPRIV, I believe that getting this type of
discovery to work well in all cases is quite hard (especially if one
has
security concerns regarding an attacker who may try to impersonate a
legitimate provider of the service [be it ALTO or LIS]).
Currently, the work in GEOPRIV is still incomplete, but I would
encourage anyone whose been thinking about ALTO discovery to read
draft-ietf-geopriv-lis-discovery-08, and if you have any insights on
how
to improve the GEOPRIV document based on your experience with ALTO,
please send comments to the GEOPRIV list (and the authors). Also,
perhaps we can get several people who have been thinking about GEOPRIV
discovery to review the ALTO discovery documents. (I'm happy to
volunteer, though I'm definitely not as much of an expert on this topic
as Martin and James, who I have been kind enough to CC <grin>).
- Matt Lepinski
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
--
Richard Bennett
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
