Re: [p2pi] Charter and problem statement
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [p2pi] Charter and problem statement



Stanislav Shalunov wrote:
> The general problem of overlay routing and how to best expose
> information for it is big and hard.
> 
> The problem of caching, on the other hand, is well-defined, easily
> scoped, and easy to agree on.  Cache tracker location is a pure and
> simple engineering problem.  Routing information exposure has a
> substantial research component.
> 
> This charter does not let the possible WG solve the easy problem -- in
> fact, it does not even contain the word "cache".  Instead, it proposes
> a particular solution (oracle) for the more complicated routing
> information exposure problem, before the problem has even been scoped.

Ok, I see that the first change must be on the term "oracle". It wasn't
of course meant to push any particular solution; in our mind, "oracle"
could be any source of topology information, including the IDIPS
"sorting oracle" as well as the P4P iTracker or the Ono/Akamai redirect
server.

That said, I understand caches as "special" peers that can be
transparently handled by the peer selection service we are trying to
standardize (as suggested in S2.1.1 of the problem statement).
Alternatively, we would have to work on some sort of
application-dependent cache location mechanism, which, AFAICT, is not
what most people here want to pursue and I don't think is what you are
proposing. Can you suggest a rewording for the current charter to best
address caching issues?

Finally, the survey draft references several solutions for addressing
the topology information exposure problem, which have proved in the real
world to be beneficial to P2P applications in the first place (and some
to ISPs as well). I really don't want people to think that we are going
to invent a new one; instead, what we are proposing is just to define a
standard interface for existing and future peer selection optimization
services, in order to ease their adoption by different P2P and non-P2P
applications.

If you agree, but don't see it reflected in the charter, feel free to
propose alternative text.

-- 
Ciao,
Enrico

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.