Subject: Re: [alto] ALTO Discovery and draft-ietf-geopriv-lis-discovery

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Mar 2009 17:18:33 -0500

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-masked]]
> Sent: Thursday, 26 March 2009 3:03 PM
> To: [email-masked]
> 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]

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 11:16:12 -0700

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:

--Martin

-----Original Message-----
From: Matt Lepinski [mailto:[email-masked]]
Sent: Thursday, 26 March 2009 3:03 PM
To: [email-masked]
Cc: Thomson, Martin; Winterbottom, James
Subject: ALTO Discovery and draft-ietf-geopriv-lis-discovery

- 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-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 27 Mar 2009 20:40:54 -0500

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-masked]] 
Sent: Friday, 27 March 2009 11:16 AM
To: Thomson, Martin
Cc: Matt Lepinski; [email-masked]; 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: 

--Martin

-----Original Message-----
From: Matt Lepinski [mailto:[email-masked]]
Sent: Thursday, 26 March 2009 3:03 PM
To: [email-masked]
Cc: Thomson, Martin; Winterbottom, James
Subject: ALTO Discovery and draft-ietf-geopriv-lis-discovery

- Matt Lepinski

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 19:25:25 -0700

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

-- 
Richard Bennett