Subject: Re: [alto] FWD: I-D Action:draft-kiesel-alto-3pdisc-00.txt

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 08 Sep 2009 15:25:14 +0800

Hi,kiesel

Well done. 
Would you be kind to explain some issues?
1, Do you have some example in mind when you point out "Peer-ID" in Approach
#3? What kind of info can uniquely identify a client or provider behind
NATs? And what kind of info, which client can obtain without much effort,
can uniquely identify one without NATs other than IP Add.
2, As far as I know, there seems no way to figure out whether 2 clients are
behind the same NAT, therefore no good way to do intra-domain optimization,
even for Approach #3, #4 and #5. So could you tell how to do intra-domain
optimization in these scenarios?

Thank you very much.

Regards

Yingjie Gu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sebastian Kiesel
> Sent: Thursday, August 27, 2009 2:07 AM
> To: [email-masked]
> Subject: [alto] FWD: I-D Action:draft-kiesel-alto-3pdisc-00.txt
> 
> Hi,
> 
> Marco and I have created a document that details the issues 
> about third-party ALTO server discovery, which were raised in 
> Stockholm.  Comments welcome.
> 
> Thanks,
> 
>    Marco and Sebastian
> 
> 
> ----- Forwarded message from [email-masked] -----
> 
> From: [email-masked]
> To: [email-masked]
> Subject: I-D Action:draft-kiesel-alto-3pdisc-00.txt
> Date: Wed, 26 Aug 2009 11:00:01 -0700 (PDT)
> Reply-To: [email-masked]
> List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : Third-party ALTO server discovery
> 	Author(s)       : S. Kiesel, M. Tomsu
> 	Filename        : draft-kiesel-alto-3pdisc-00.txt
> 	Pages           : 15
> 	Date            : 2009-08-26
> 
> The goal of Application-Layer Traffic Optimization (ALTO) is 
> to provide guidance to applications, which have to select one 
> or several hosts from a set of candidates, that are able to 
> provide a desired resource.
> 
> This document describes why a third-party ALTO server 
> discovery mechanism is required for an important class of 
> applications, namely tracker-based P2P applications.  Several 
> solution approaches are classified and evaluated.  The 
> conclusion is that further work is required to standardize a 
> protocol and procedures that follow one specific approach.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kiesel-alto-3pdisc-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> ----- End forwarded message -----
> 
> -- 
> Sebastian Kiesel            mailto:[email-masked]
> Network Research Division   tel:+49-6221-4342-232   
> fax:+49-6221-4342-155
> NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 
> Heidelberg, Germany
> --
> NEC Europe Limited          Registered in England 2832014
> Registered Office           NEC House, 1 Victoria Road, London W3 6BL
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 23 Sep 2009 16:38:23 +0200

Hi,

> Well done. 

thx.

> 1, Do you have some example in mind when you point out "Peer-ID" in
> Approach #3? What kind of info can uniquely identify a client or
> provider behind NATs? 

Foreword: when we were writing about intra-domain optimization
behind the NAT we were thinking of Large Scale NAT / Carrier Grade NAT
boxes with thousands to millions of users behind one NAT (please, before
screaming at us, read the concluding remark below).
If the NAT is only a "DSL router" / residential gateway it is probably
sufficient to do the optimization based on its external address.

We had the following scenario and message flow in mind:

Network operators that use Large Scale NAT assign a local ID (L-ID) to
the clients behind the NAT.  The L-ID needs to be unique only among all
users behind the same NAT.  In the easiest case this could be the
client's "internal" IP address. If NATs are cascaded one would need
another mechanism, e.g., assigning a L-ID by means of DHCP, to ensure
uniqueness.

If the P2P client contacts the tracker (which is assumed to be
"somewhere in the Internet", i.e., outside the NAT), it includes its
L-ID in the message to the tracker. That's why an extension to the P2P
application protocol would be needed.

The IP source address of the message to the tracker will be rewritten
by the NAT to NATextIP, i.e., the tracker will receive a message
from NATextIP.  The tracker will store in its database 
that (NATextIP, L-ID) is now taking part in the swarm.
We assume that the tracker has also stored the (NATextIP, L-ID) tuples
of other peers it knows.

The tracker invokes the third-party ALTO server discovery mechanism,
with NATextIP as parameter, to find the "right" ALTO server, which can
give guidance to all clients behind the NAT.

The tracker asks the ALTO server for guidance and 
includes (NATextIP, L-ID) of the peer asking for content in the query.
The tracker can give guidance regarding (NATextIP, L-ID) tuples of peers
from the same domain and regarding IP addresses of peers in other domains.

That way one could implement intra-domain optimization.

> And what kind of info, which client can obtain without much effort,

In the example above, the unique ID is the concatenation of the external
IP and an additional L-ID which could be ommitted (or set to zero) if
the client is not behind a NAT.

> optimization in these scenarios?

There are some heuristics that might be able to tell, but we could also
imagine to introduce an explicit way (e.g., by means of DHCP) to tell
the client that it is behind a NAT.

Concluding remark: draft-kiesel-alto-3pdisc-00 does NOT recommend that
the ALTO WG should follow this approach. However, the authors have
talked to persons who believe, that a scheme for intra-domain
optimization behind Large Scale NATs will be needed in the future.

Any feedback on whether these approaches should be further elaborated
(and volunteers to contribute) are most welcome!

Thanks,

    Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL