Hi,
On Tue, Sep 08, 2009 at 03:25:14PM +0800, Y.J. Gu wrote:
> Hi,kiesel
>
> Well done.
thx.
> 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?
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,
> can uniquely identify one without NATs other than IP Add.
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.
> 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?
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 protected]
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 protected]
https://www.ietf.org/mailman/listinfo/alto
