Subject: [alto] Updating the requirements draft

From: Enrico Marocco <[email-masked]>
Date: Wed, 1 Jul 2009 09:58:13 +0200

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?

-- 
Ciao,
Enrico

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 1 Jul 2009 05:06:51 -0400

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 01 Jul 2009 02:38:16 -0700

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:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 1 Jul 2009 14:46:56 +0200

> queries for different clients? If yes, could you elaborate on the details of

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

---

From: John Leslie <[email-masked]>
Date: Wed, 1 Jul 2009 09:22:49 -0400

> 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
" the clients that information is about

although I would quite agree that if a customer itself passes on what
its provider's ALTO server has disclosed to it, the customer has no basis
for a claim against the provider for privacy violation.

   Privacy law is _quite_ different in different jurisidictions: we
should steer clear of it when writing an international standard.

--
John Leslie <[email-masked]>

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 1 Jul 2009 16:50:11 +0200

> estimates obtained by other means.

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

> (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).

> " 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"
seems appropriate ;)

-- 
Ciao,
Enrico