![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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