Re: [p2pi] why i hummed no
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [p2pi] why i hummed no



Louise,

Thanks for your feedback.

comments are inline.

> Chairs asked for feedback from the no's , so here is mine
>
> I think the general problem space - peer to peer (overlay) networks making
> routing choices that have bad effects on the lower layers is a very big
> and important problem
>
> I think it is very important that we understand what solutions we should
> be working towards very well as I would hate to see bright and motivated
> people wasting time working on the wrong things, as this could divert
> effort from better solutions
>
> my concern is that an oracle approach might not be terribly helpful
>
> neither the p2p ap or the network have any reason to trust each other and
> the goals they are trying to achieve are likely to be different - how do i
> know you are telling me the highest bandwidth not the lowest cost choice?
>
of course, this is why it should be optional. It is not a good point for
the provider to give inaccurate information. Indeed, eventually, the
client will remark that performances are better (with some application
level feedback) while not using the oracle and will decide to stop using
the oracle -> goto step 0!

> the information recieved could be used in ways to harm the network -
> deliberatly choosing the non-preferred routes
>
That is true, and must be added in the requirements. But systematically
using a bad path is already possible thanks to looking glasses,
measurements and other useful tools.

> the information might influenece the p2p application, but if the actual
> bandwidth (or lowest delay or lowest jitter etc etc) available from a
> non-preferred peer is higher than that then the non-preferred peer will be
> used, therefore analysis is required to try and quantify the likely
> benefit of such a scheme. there needs to be good corrolation between the
> oracle output and the p2p needs.
>
IMHO, the main point for the WG is to standardize a way to communicate,
the optimization will depends on the implementation. And it could even
open a new market with different third parties offering oracle systems
(?).

> To really do the path choice thing sensibly in my mind requires dynamic
> information which can not be obtained from an oracle.
Why dynamic information are not possible with an oracle? We did dynamic
path selection with IDIPS/LISP and it works fine.
> Indeed from a
> provider perspective, this dynamic infomation could be more/as important
> also - I would want to direct you to lightly loaded links as directing you
> to a cheap, short high bandwidth but congested link is likely to do me
> more harm as well
>
sure, the information is important for both so why not combine them in a
black box a-la oracle? Seems not stupid for me to have client sending
information to the oracle and the operator doing the same to the oracle.
The oracle just combine information from different sources and provide
this information later to who needs it (note: the oracle must take care of
not being a source of information leakage between the different worlds for
economical and privacy reasons).
> I would like to see these issues considered better before rushing into
> solution space
>
Except the security point you mentioned, the points have already been
studied, you can find a lot of good papers talking about that.
> Louise
>
>
Cheers,

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


_______________________________________________
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.