Subject: [alto] New draft on an ALTO architecture submitted

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 04 Mar 2009 17:22:21 -0500

Hi All,

We just submitted a new draft:
http://www.ietf.org/internet-drafts/draft-yang-alto-architecture-00.txt

Comments greatly appreciated!

Richard
http://www.cs.yale.edu/~yry/

Title: An Architecture of ALTO for P2P Applications

Abstract: ALTO enables Internet Service Providers (ISPs) and network
application software distributors to work jointly and cooperatively to
reduce network resource consumption and to improve application
performance. In this document, we specify an architecture for integrating
ALTO into peer-to-peer (P2P) applications.

---

From: songhaibin 64081 <[email-masked]>
Date: Thu, 05 Mar 2009 17:25:35 +0800

Hi all,

We also submit an ALTO server discovery draft. Here is the link:

http://tools.ietf.org/id/draft-song-alto-server-discovery-00.txt

Now there are two drafts on ALTO server discovery. I think they have commonness and differences. Our draft mainly focuses on the scenario where network operators provide the alto servers. The solution has the consideration for residential gateways when using DHCP option to retrieve the alto service name. We also take into account the discovery process by end terminals and application trackers(or proxies). These two drafts can be of compleme
ntary to each other.

Any comments are appreciated!

Best Regards!
Song Haibin

---

From: Gustavo Garcia Bernardo <[email-masked]>
Date: Fri, 06 Mar 2009 00:07:35 +0100

Hi Song,

Our ALTO Discovery document (draft-wang-alto-discovery-00) doesn't try to make a concrete proposal on a discovery protocol until the ALTO protocol and architecture are better defined.   At this point the draft addresses some considerations to be taken into account to decide the discovery mechanism, and describes some existing discovery protocols explaining how they could be applied to ALTO, their advantages and their limitations.    Our idea is to avoid defining new discovery protocols and reuse the existing ones describing how they can be applied to the ALTO use case.

BR,
G.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of songhaibin 64081 [[email-masked]]
Sent: Thursday, March 05, 2009 10:25 AM
To: [email-masked]
Subject: [alto] ALTO server discovery

Hi all,

Best Regards!
Song Haibin
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Gustavo Garcia Bernardo <[email-masked]>
Date: Fri, 06 Mar 2009 00:15:55 +0100

Hi,

I have some comments on the mechanism described in song-discovery for the ALTO server discovery by end terminals:

It seems to require the configuration of the ALTO DNS SRV name in the DHCP server.  Perhaps this could make more complicated the deployment of the solution.  It could be possible to use a reverse DNS lookup to discover the ALTO service name.   This was previously described in BEP-22.

The SRV based DNS discovery allows to retrieve the IP Address and port of the ALTO server.   A mechanism based in U-NAPTR could be more flexible and allow the discovery of a url (for example for the case of InfoExport where a HTTP url is needed).     This U-NAPTR based discovery is used in other discovery protocols like draft-ietf-geopriv-lis-discovery-07.

Best Regards,
G.

Hi all,

Best Regards!
Song Haibin

---

From: songhaibin 64081 <[email-masked]>
Date: Fri, 06 Mar 2009 10:45:48 +0800

Dear Gustavo,

> 
> I have some comments on the mechanism described in song-discovery 
> for the ALTO server discovery by end terminals:
> 
> It seems to require the configuration of the ALTO DNS SRV name in 
> the DHCP server.  Perhaps this could make more complicated the 
> deployment of the solution.  It could be possible to use a reverse 
> DNS lookup to discover the ALTO service name.   This was 
> previously described in BEP-22.

IMHO, in this scenario, DHCP is an simple way to get the ALTO service name although you need the configuration on the DHCP server in ISP network. If you use BEP-22, there is still a lot of work to do, e.g., you need to implement STUN servers or other mechanisms to find your public address, and the hierachical network address structure makes it a little more complicated when you don't depend on some central mechanism. I am also a little conf
used with using the DNS reverse lookup for host name when I have a host name xx.xx.myCompany.com and the ALTO service is provided by my ISP with the service name _alto._tcp._myISP.com.

> The SRV based DNS discovery allows to retrieve the IP Address and 
> port of the ALTO server.   A mechanism based in U-NAPTR could be 
> more flexible and allow the discovery of a url (for example for 
> the case of InfoExport where a HTTP url is needed).     This U-
> NAPTR based discovery is used in other discovery protocols like 
> draft-ietf-geopriv-lis-discovery-07.

Thanks for the good reference. I will try to understand that draft. Anyway, the existing DNS SRV mechanism works.

Best Regards!
Song Haibin

> Now there are two drafts on ALTO server discovery. I think they 
> have commonness and differences. Our draft mainly focuses on the 
> scenario where network operators provide the alto servers. The 
> solution has the consideration for residential gateways when using 
> DHCP option to retrieve the alto service name. We also take into 
> account the discovery process by end terminals and application 
> trackers(or proxies). These two drafts can be of compleme
> ntary to each other.
>

---

From: songhaibin 64081 <[email-masked]>
Date: Fri, 06 Mar 2009 10:49:56 +0800

Dear Gustavo,

> Our idea is to avoid 
> defining new discovery protocols and reuse the existing ones 
> describing how they can be applied to the ALTO use case.
> 

We have the same thought, and that's also what we did in draft-song-alto-server-discovery.

Regards,
Haibin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 6 Mar 2009 11:20:49 +0100

Hi all,

Just a (probably) very silly question: 

Isn't it way too early to get a discussion about ALTO server discovery started? And also (as Lisa pointed out) there are already many mechanisms to discover hosts, server, and services. 

I see more the need to spend cycles on ALTO problem space, reqs, basically where do we go with that?!

Just my two cents

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> songhaibin 64081
> Sent: Friday, March 06, 2009 3:50 AM
> To: Gustavo Garcia Bernardo
> Cc: [email-masked]
> Subject: Re: [alto] ALTO server discovery
> 
> Dear Gustavo,
> 
> > Our idea is to avoid

---

From: "Roni Even" <[email-masked]>
Date: Fri, 6 Mar 2009 13:34:58 +0200

Martin,
This is from the WG charter

- In order to query the ALTO server, clients must first know one or
more ALTO servers that might provide useful information.  The WG
will look at service discovery mechanisms that are in use, or
defined elsewhere (e.g. based on DNS SRV records or DHCP options).
If such discovery mechanisms can be reused, the WG will produce a
document to specify how they may be adopted for locating such
servers.  However, a new, general-purpose service discovery
mechanism is not in scope.

So this is chartered work.

Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Stiemerling
Sent: Friday, March 06, 2009 12:21 PM
To: songhaibin 64081; Gustavo Garcia Bernardo
Cc: [email-masked]
Subject: Re: [alto] ALTO server discovery

Hi all,

Isn't it way too early to get a discussion about ALTO server discovery
started? And also (as Lisa pointed out) there are already many mechanisms to
discover hosts, server, and services. 

I see more the need to spend cycles on ALTO problem space, reqs, basically
where do we go with that?!

Just my two cents

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 6 Mar 2009 14:03:40 +0100

Well, I haven't doubt that it is on our charter, but I have questioned the timing. 

  Martin

[email-masked]

> From: Roni Even [mailto:[email-masked]]
> Sent: Friday, March 06, 2009 12:35 PM
> To: Martin Stiemerling; 'songhaibin 64081'; 'Gustavo Garcia Bernardo'
> Cc: [email-masked]
> Subject: RE: [alto] ALTO server discovery
> 
> Martin,

---

From: "Roni Even" <[email-masked]>
Date: Fri, 6 Mar 2009 16:22:21 +0200

Martin,
Priority is up to the chairs based on availability of documents, their
progress and the milestones. The group will probably decide on which
documents will be the initial WG documents and progress them accordingly. 

Look at the milestone for the priority order

Apr 2009    Working Group Last Call for problem statement  
Jun 2009    Submit problem statement to IESG as Informational  
Aug 2009    Working Group Last Call for requirements document  
Oct 2009    Submit requirements document to IESG as Informational  
Jan 2010    Working Group Last Call for request/response protocol  
Jan 2010    Working Group Last Call for usage document for communicating
network preferences  
Mar 2010    Submit request/response protocol to IESG as Proposed Standard  
Mar 2010    Submit usage document to IESG as Proposed Standard  
May 2010    Working Group Last Call of discovery mechanism  
Jul 2010    Submit discovery mechanism to IESG as Proposed Standard  
Aug 2010    Dissolve or re-charter  

The service discovery is last on the list but that does not mean that we do
not need to work on it. 

Roni Even

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, March 06, 2009 3:04 PM
To: Roni Even; songhaibin 64081; Gustavo Garcia Bernardo
Cc: [email-masked]
Subject: RE: [alto] ALTO server discovery

Well, I haven't doubt that it is on our charter, but I have questioned the
timing. 

  Martin

[email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 06 Mar 2009 08:36:29 -0600

> documents will be the initial WG documents and progress them accordingly. 
[...]

In the Minneapolis IETF, we (i.e., the chairs) had solicited
a few interested parties for this work; we were also approached
by others that were interested in doing the work on server
discovery.

Being that no good deed goes unpunished in the IETF, it does
not help to get in the way of progress if there is interest
in doing the work.  Clearly, to a certain extent the drafts
are more into an exploratory mode at present, with nothing
being finalized at this early a stage.  But it does help to
lay the options out for the WG to mull over.  As it turns out,
the two drafts, produced independently of each other, do
have some aspects of commonality (which is a good thing.)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/