> > S 6.4.1.2 describes a retransmission mechanism for datagram transports > but doesn't specify when to give up and assume that the connection has > failed. We probably want to specify some sort of drop-dead time. > Arguable, this needs to be shorter than the overall message > failure time > (15 seconds) or messages won't get rerouted properly if a link dies. > > On a related note, the TCP transports don't have any kind of > explicit ACK at all at the application layer, though of course > you will eventually get some TCP transmission failure, which > is very slow. Do we want to extend the existing datagram framing to > all transports and include a fast timeout?
I think the fast detection is important for routing in the overlay. In IP network, there are several mechanisms, such as BFD, MPLS OAM, to make the FRR (Fast ReRoute) possible. There are a lot of path between two nodes, so IMHO, I think this feature is very useful for P2P system. On the other hand, maybe other solutions could benefit from the fast detection. For example, a problem with relay peer and direct response is when they may fail and should fall back to symmetric recursive. In the case where the requesting peer has a public address but is not sure whether it is behind firewall or not, the destination peer may establish the connection first and then send the response. In this case, if the explicit ACK is introudced, the destination peer could know whether the response has arrived at the requesting peer succefully. In the case where the request peer is behind NAT, it may use the RELAY peer to help in returning response. In this case, the explicit ACK could be extended to check whether there is really a workable connection between RELAY peer and the requesting peer, so that the destination could decide whether send the response by using symmetric or not. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
