I agree with what you said.
One way to achieve direct response is to encode ICE candidates as a
forwarding option in request and response. In fact, P2PP did allow
encoding ICE candidates in every request and response for speeding up
overlay traversals for the scenarios you described.
If forwarding headers are used to encode ICE candidates, I suggest that
they be defined in a separate document.
For scenario 3, node state likely becomes a non-issue with parallel
searches and iterative routing. Practically, there is always the backup of
relying on the central server after a certain number of retries, a
solution adopted by Skype.
In general, deployment specific optimizations (which will likely be many),
should be defined in separate documents.
regards,
salman
On Thu, 10 Dec 2009, Bruce Lowekamp wrote:
First, I apologize for not being able to contribute to the mailing
list recently. Due to the nature of my work at Skype Labs, I was not
able to contribute to the IETF at the time. The nature of my work at
Skype has now changed and I now hope to be able to return to
contributing on a regular basis.
On the issue of the WGLC for the RELOAD base draft, I am concerned
that the issue of how routing is done has not been adequately
addressed by this draft. I had hoped that draft-jiang-p2psip-relay
would make more progress in addressing these issues together with work
on the base draft, but that progress has been slow. I don't think we
can move forward on the base draft until we address how to resolve
these issues and are sure we have an appropriate way forward from the
combination of the base draft and that (or any other) extension drafts
that emerge to address these issues.
Looking at the problem space, there are three types of deployments we
need to address
1) overlays where the majority of peers are behind NATs
2) overlays where no peers are behind NAT/firewalls (provider provisioned)
3) overlays where there is an effort to select peers that are not
behind NATs, but connectivity is not assured
Currently the draft uses SRR, which addresses all of these cases.
However, it imposes a significant penalty on cases where SRR isn't
needed because there are no NATs in the way, i.e. raw IP addresses
could be used. The analysis of these problems presented so far has
tended to look at the query-response pattern, but there are actually
many applications in a P2P overlay that are not search---where a
node's location is known in advance. In that case, there is a clearer
argument for having an IP address to directly contact the target node,
and being able to use the Node-ID as a backup. Even in a "classic"
p2psip-style lookup followed by an AppAttach, SRR-only routing results
in at least 4 log(N) traversals through the overlay, whereas if DRR/RP
is available, only one is required.
With that said, I stand by my earlier comments on the importance of
not introducing additional complexity into the base protocol. But we
can't stick our heads in the sand, either.
I propose we should ensure that the base draft address scenarios (1)
and (2) above in efficient ways. In other words, retain SRR, but
specify a way of encoding IP & Node ID together in a Destination so
that messages can be sent that way. Import flags so that direct
routing can be used and address the state issue on intermediate peers.
Scenario (3), where it may not be possible to know in advance whether
direct or overlay routing is needed, is more complicated and needs to
be outside the scope of the base draft. However, we do need to make
sure that there is nothing fundamentally flawed in the base protocol
that prevents adaptive or variable routing being done as an extension.
As has often been discussed in this group, SRR has the advantage that
it always works. That means RELOAD needs to support it, but if we
expect RELOAD to be adopted in the real world, we need to make sure it
allows the optimizations that can (and should) be done across the full
range of deployment possibilities.
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
