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

From: Song Haibin <[email-masked]>
Date: Thu, 02 Apr 2009 10:48:51 +0800

Hi Richard,
 
Your explanation makes me more clear about the situation of RGs. I'm glad
that DHCP Container option can provide great help to the RG/home router
problem. Unlike DHCP relay, with the support of the Container option, a RG
doesn't need to understand any of the DHCP options that are retrieved from
the ISP's DHCP server and pass through the RG to its consumer clients. I
think more and more RGs will support this Container option. It's very useful
not only for ALTO service discovery but also for other service
configurations to home clients. We have considerations to use this option in
the discovery draft
http://tools.ietf.org/html/draft-song-alto-server-discovery-00#section-3.2.1
.
 
BTW, the DHCP Container draft is now in the proceeding of IESG last call as
a proposed standard. It's reasonable to reuse it here.
http://www.ietf.org/internet-drafts/draft-ietf-dhc-container-opt-05.txt 

 
  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Bennett
Sent: Saturday, March 28, 2009 10:25 AM
To: Thomson, Martin
Cc: Matt Lepinski; Winterbottom, James; [email-masked]
Subject: Re: [alto] ALTO Discovery and draft-ietf-geopriv-lis-discovery

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-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: 

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]

_______________________________________________

alto mailing list

[email-masked]

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