Henry Sinnreich wrote:
I have changed the title of the topic.
It would be better if the connect message is not designed specially for work
with ICE. So that other information than what ICE needed could also be
exchanged between two end nodes;
>
This is just one instance that illustrates how/why HIP can contribute to a
better P2P SIP with NAT traversal, mobility, etc. There have been previous
posts to this effect, but the attached would make a great example in a usage
scenario of using HIP for P2PSIP.
Yes, I know, developing HIP code looks like opening a whole new can of
worms, but nothing compares to what we are looking at now when trying to
traverse NAT, support mobility, multihoming, etc. for each application
protocol and their various flavors separately.
I have copied some HIP folks :-) to help me out in case people have doubts
about this axiom.
I think that the key discussions concerning HIP have focused not on
whether it would be useful to applications, but on the exact layering
required to make it work. All proposals (with and without HIP) have ICE
at the bottom layer, but how the applications use it and whether HIP is
used for the peer protocol connections have varied.
Taking Section 3.2 of hip-bone-01 as an example, that proposal routes
the I1 and I2 messages across the overlay (taking the place of the HIP
rendezvous server). reload-04 suggests accomplishing this by defining a
HIP Tunnel Usage (in another draft). I'm very interested in the hip-bone
authors' opinion of whether this technique meets their requirements for
routing these messages.
Bruce
Henry
On 6/18/08 10:43 PM, "JiangXingFeng" <[EMAIL PROTECTED]> wrote:
Hi,
See inline.
Regards
JiangXingFeng
Good point - I'm not really sure what to do here. I can see the use
case you are making for connects to an ID that is different than the
id of the node that ends up connecting. The only way I see to allow
that is to remove the check but I'd have to think about if this breaks
anything.
It would be better if the connect message is not designed specially for work
with ICE. So that other information than what ICE needed could also be
exchanged between two end nodes;
Yes, I agree some sort of keep alive is needed to detect liveness on
these connection. We also need to be able to deal with receiving a TCP
RST for the TLS connections.
IMHO, a new keepalvie message is needed and could detect the connection
failure in time. A keepalive mechanism between two peers could also be used
to distribute some information like peers' capability or their changes so
that other peers could know the changes in time.
4. In section 3.3.1, some routing alternatives are listed. As for
direct
response and relay peer, I think they could be well used together
with the
symmetric routing proposed in RELOAD-04 although there are some
limits with
their use. For example, the original peer could convey its contact
address
and/or the chosen relay peer information to the destination in the
request,
it's
up to the destination peer to choose whether send the response in
all ways
or
only in a subset of ways. In this way, they could bring enhancement
to the
symmetric routing.
As for routing in the overlay, my major concern is still the
stablity of the
reverse connection due to the churn. In my mind, symmetric routing
works
better
where the hops for the request is not big and direct response and
relay peer
could provide much help when the hops is big. I've done a few work on
comparing
different routing modes listed in RELOAD-4 which has not finished
yet. If
some
data comes out, I will share them with the community.
I suspect this is an important topic worth of it's own thread. I look
forward to seeing your work and I hope this is the sort of thing we
end up getting time in the WG meetings to talk about because it is
important. My main concern with all these is that the routing works
well enough that two partitioned networks that each have a ring can
successfully merge back together. Any scheme where that does not
allow this would seem somewhat broken to me.
As for partition, what I see the peer could do after he knows that is to
restart a join-like operation. The direct response and relay peer work in
the partition situation in the same way as in other situations. Am I missing
something?
What I suggest is to integrate symmetric routing mode, direct response,
relay peer into an integral routing mechanism and could work more efficient
than using a single candidate mechanism.
Well, I'm going to blame some other author on the 2^32 :-) but
seriously this is allowed to be much larger than the IP MTU. The
transport will need to deal with fragmenting and sending this. Clearly
TCP already does this and in the case of UDP, reload provides
fragmentation. There is not too much on that yet as it's fairly well
understood how to do it and we just need to go add text and work with
the transport folks on getting it right.
Basically, I don't like the fragmentation/reassembly idea. Because I think
it will introduce some security threats. For instance, a malicious peer may
send most of the fragments and does not send the rest on purpose, so that
the reassembly will not succeed in the destination peer. Then DoS attack
happens and will make the overlay unstable.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
