headers
Song Haibin | 1 Jul 2009 04:34
Favicon

Comments to draft-ietf-alto-reqs-00

Hi, 

REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be independent of
specific link-layer protocols or access network architectures.  For example,
many broadband access networks use DHCP for configuration, while others use
PPPoE. In contrast, DNS is available in virtually all Internet access
networks.

What is the meaning of "independent of ..."? I saw a lot of discovery
mechanisms related to DHCP, please refer to
http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-11.

Best Regards,
Haibin
Skype: alexsonghw
Permalink | Reply | 3 comments |
headers
Enrico Marocco | 1 Jul 2009 09:58
Picon
Favicon

Updating the requirements draft

Folks,

the recent WGLC discussion has brought to surface a couple of not
exactly new issues I think it would be worth keeping track of, possibly
in the alto-reqs draft we decided to keep alive to reflect ongoing
consensus.

A first consideration has to do with the information an ALTO server may
want to pass to its clients. Even though, to preserve users' privacy, a
server should take care of disclosing sensible information only to the
clients that information is about (e.g. it's OK to tell a user its own
provisioned bandwidth, less its peers'), there is no way to control the
redistribution of any bit of information. This means that, if an ALTO
service provider is willing to tell something to someone, it must be
aware that that information may reach anyone and everyone. I think that
having it clearly stated somewhere -- maybe as informative text in
section 3.3 -- could help avoid annoying misconceptions.

Another thing that's been mentioned a few times, but not really
discussed, is related to how the information is provided to the clients.
 Since the amount of such information may be fairly large, it could be
desirable to have a mechanism for delta exchanges; this would be
particularly useful when the client, e.g. located in a tracker, queries
ALTO servers on behalf of several peers. Some proposals already have
such a mechanism, while others could be easily extended, so I think it
would be worth adding this to the requirements, maybe as a SHOULD.

Do people think that tracking such and similar issues is worth the
effort? Any further elaboration on the above considerations?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Reinaldo Penno | 1 Jul 2009 11:06
Favicon

Re: Updating the requirements draft

Hello Enrico,

I do not have the details on the delta approach that you have in mind, so
before I voice my opinion I have a few basic question: will this requirement
make the protocol stateful?

In other words, will the Alto Server need to keep state across different
queries for different clients? If yes, could you elaborate on the details of
the proposal? 

Thanks,

Reinaldo

On 7/1/09 12:58 AM, "Enrico Marocco" <enrico.marocco <at> telecomitalia.it>
wrote:

> Another thing that's been mentioned a few times, but not really
> discussed, is related to how the information is provided to the clients.
>  Since the amount of such information may be fairly large, it could be
> desirable to have a mechanism for delta exchanges; this would be
> particularly useful when the client, e.g. located in a tracker, queries
> ALTO servers on behalf of several peers. Some proposals already have
> such a mechanism, while others could be easily extended, so I think it
> would be worth adding this to the requirements, maybe as a SHOULD.
> 
> Do people think that tracking such and similar issues is worth the
> effort? Any further elaboration on the above considerations?
Permalink | Reply | 2 comments |
headers
Y. Richard Yang | 1 Jul 2009 11:38
Picon
Favicon

Re: Updating the requirements draft

Hi Enrico,

Is there a pointer to related delta approaches? In the P4P design, one 
option considered was the delta encoding of PIDMap update, which can be 
the largest data structure in the P4P-based approach (the PIDMap for 
some largest ISP can be on the other of hundreds of KB to a couple MB). 
Specifically, each PIDMap distributed has a version number. When the 
PIDMap is updated, the version# is increased, and an rdiff (patch) is 
generated. Then, a client update specifies known PID version#, and the 
portal server replies with the diff to the current version#. This option 
is not fully implemented. What other delta encoding are we considering?

Thanks.

Richard

Reinaldo Penno wrote:
> Hello Enrico,
>
> I do not have the details on the delta approach that you have in mind, so
> before I voice my opinion I have a few basic question: will this requirement
> make the protocol stateful?
>
> In other words, will the Alto Server need to keep state across different
> queries for different clients? If yes, could you elaborate on the details of
> the proposal? 
>
> Thanks,
>
> Reinaldo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Enrico Marocco | 1 Jul 2009 14:46
Picon
Favicon

Re: Updating the requirements draft

Reinaldo Penno wrote:
> I do not have the details on the delta approach that you have in mind, so
> before I voice my opinion I have a few basic question: will this requirement
> make the protocol stateful?
> 
> In other words, will the Alto Server need to keep state across different
> queries for different clients? If yes, could you elaborate on the details of
> the proposal? 

This is actually a good question. Undoubtedly, for being able to
exchange deltas, the status must be maintained somewhere. I think the
client, not the server, should take care of that and the protocol just
provide a means to identify where the delta begins. Richard has
described a versioning approach to achieve that in P4P and, I guess,
also in the original Infoexport solution. With other approaches -- I
hope this also somewhat answers Richard's question -- where the guidance
service is basically a sorting function that applies to IPs, network
prefixes and/or generic IDs, it could be achieved adding absolute
priority values to the entries in the ordered list, thus allowing the
client to merge the deltas with the data previously obtained.

All this is of course just off the top of my head; I'd be very
interested in understanding how important people think such a mechanism
would be and, equally important, what would be the cost in terms of
added complexity.

--

-- 
Ciao,
Enrico
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Leslie | 1 Jul 2009 15:22
Favicon

Re: Updating the requirements draft

Enrico Marocco <enrico.marocco <at> telecomitalia.it> wrote:
> 
> A first consideration has to do with the information an ALTO server may
> want to pass to its clients. Even though, to preserve users' privacy, a
> server should take care of disclosing sensible information only to the
> clients that information is about (e.g. it's OK to tell a user its own
> provisioned bandwidth, less its peers'), there is no way to control the
> redistribution of any bit of information. This means that, if an ALTO
> service provider is willing to tell something to someone, it must be
> aware that that information may reach anyone and everyone. I think that
> having it clearly stated somewhere -- maybe as informative text in
> section 3.3 -- could help avoid annoying misconceptions.

   I see very little need to state that in a "requirements" draft (or,
really, in any ALTO document), but if we were to go that far, I would
want to add language to the effect that if the provider's ALTO server
_doesn't_ provide the information, other ALTO servers are likely to use
estimates obtained by other means.

   (To the extent we're talking about "provisioned bandwidth," I'm not
convinced such a number is particularly useful for cable or wireless
customers, though it is probably useful for DSL customers.)

   I recommend we go no farther than to say that privacy concerns
between a provider and customer are outside the scope of this work.
(Let the market work out what the balance should be.)

   I do not agree with the "should" in:
" 
" a server should take care of disclosing sensible information only to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Enrico Marocco | 1 Jul 2009 16:50
Picon
Favicon

Re: Updating the requirements draft

John Leslie wrote:
>    I see very little need to state that in a "requirements" draft (or,
> really, in any ALTO document), but if we were to go that far, I would
> want to add language to the effect that if the provider's ALTO server
> _doesn't_ provide the information, other ALTO servers are likely to use
> estimates obtained by other means.

Yep, that would be quite in the spirit of my initial comment.

>    I recommend we go no farther than to say that privacy concerns
> between a provider and customer are outside the scope of this work.
> (Let the market work out what the balance should be.)

Agreed. However, the protocol should provide at least basic mechanisms
to deal with privacy. Right now we have a requirement for support of
mutual authentication for clients and servers. Is that enough? While
probably servers should always be authenticated, in some cases clients
may prefer to avoid explicit authentication and have privacy addressed
on a network location basis. Of course, if we decide to address such
cases, there are implications we cannot ignore (e.g. we should define
mandatory behavior for intermediaries, or discourage/forbid
intermediaries at all).

>    I do not agree with the "should" in:
> " 
> " a server should take care of disclosing sensible information only to
> " the clients that information is about

That was actually not 2119 speak meant to go in any IETF document, just
a general consideration for whatever value of "sensible information"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Kiesel | 1 Jul 2009 23:24
Picon
Favicon

Re: Comments to draft-ietf-alto-reqs-00

Hi Haibin,

I know this section needs work, let me try to explain my reasoning.

On Wed, Jul 01, 2009 at 10:34:41AM +0800, Song Haibin wrote:
> Hi, 
> 
> REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be independent of
> specific link-layer protocols or access network architectures.  For example,
> many broadband access networks use DHCP for configuration, while others use
> PPPoE. In contrast, DNS is available in virtually all Internet access
> networks.
> 
> What is the meaning of "independent of ..."? I saw a lot of discovery
> mechanisms related to DHCP, please refer to
> http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-11.

Well, there is nothing wrong with defining a discovery mechanism based
on DHCP. However, we must be aware that there is a significant number of
broadband customers that are not configured using DHCP. For example,
virtually all residential ADSL lines in Germany use PPPoE. So a quick
conclusion would be, that if we define a DHCP option, we should also
define an equivalent for PPP.

However, there is another issue. We can imagine scenarios with several
ALTO servers, each having only partial information ("my Internet view").
A tracker performing a third-party ALTO query on behalf of a peer would
have to send the query to that ALTO server which can give the best
guidance to the considered peer.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Song Haibin | 2 Jul 2009 04:46
Favicon

Re: Comments to draft-ietf-alto-reqs-00

Hi Sebastian,

See inline.  

>I know this section needs work, let me try to explain my reasoning.
>
>
>On Wed, Jul 01, 2009 at 10:34:41AM +0800, Song Haibin wrote:
>> Hi,
>> 
>> REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be 
>> independent of specific link-layer protocols or access network 
>> architectures.  For example, many broadband access networks use DHCP 
>> for configuration, while others use PPPoE. In contrast, DNS is 
>> available in virtually all Internet access networks.
>> 
>> What is the meaning of "independent of ..."? I saw a lot of 
>discovery 
>> mechanisms related to DHCP, please refer to 
>> http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-11.
>
>Well, there is nothing wrong with defining a discovery 
>mechanism based on DHCP. However, we must be aware that there 
>is a significant number of broadband customers that are not 
>configured using DHCP. For example, virtually all residential 
>ADSL lines in Germany use PPPoE. So a quick conclusion would 
>be, that if we define a DHCP option, we should also define an 
>equivalent for PPP.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sebastian Kiesel | 2 Jul 2009 15:56
Picon
Favicon

Re: Comments to draft-ietf-alto-reqs-00

On Thu, Jul 02, 2009 at 10:46:54AM +0800, Song Haibin wrote:
> >On Wed, Jul 01, 2009 at 10:34:41AM +0800, Song Haibin wrote:
> >> REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be 
> >> independent of specific link-layer protocols or access network 
> >> architectures.  For example, many broadband access networks use DHCP 
> >> for configuration, while others use PPPoE. In contrast, DNS is 
> >> available in virtually all Internet access networks.
> >> 
> >> What is the meaning of "independent of ..."? I saw a lot of 
> >discovery 
> >> mechanisms related to DHCP, please refer to 
> >> http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-11.
> >
> >Well, there is nothing wrong with defining a discovery 
> >mechanism based on DHCP. However, we must be aware that there 
> >is a significant number of broadband customers that are not 
> >configured using DHCP. For example, virtually all residential 
> >ADSL lines in Germany use PPPoE. So a quick conclusion would 
> >be, that if we define a DHCP option, we should also define an 
> >equivalent for PPP.
> >
> 
> I think it is the ALTO service provider who should consider its network
> deployment characteristics to choose one or more appropriate discovery
> mechanisms. 

... and we probably should offer a sufficient number of standardized
discovery mechanisms to choose from, which together cover at least most
of the relevant deployment scenarios and use cases.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane