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
