Reload supports large messages, but it is missing a number of components required to make this work. In particular, there is no end-to-end congestion control, and a large message could essentially block a link between two peers long enough to force other messages (and the large message itself) to time out.
Solving this properly is likely to be quite complicated. Since our primary usage requires only the exchange of URIs and certificates, the authors would like to avoid adding the complexity necessary to handle arbitrarily large messages to the base protocol. We propose the following: the base protocol will support: - an overlay-configured (policy) maximum message size for non-direct messages * an error when a peer attempts to relay a message larger than this * a response code of some sort indicating that the reply would be larger than this size, so a direct connection is required - will not specify what the max msg size is, but will suggest that since we have an all-or-nothing fragment approach, that the ideal message size is not large. - continue to support ice & turn (+ tcp variants) the base protocol will not support, but will be designed to be extensible to include: - end-to-end reliable, congestion-controlled transport - traffic prioritization via sctp/multiple tcp's to prioritize overlay control and maintenance over bulk data transfer - such extensibility support will likely include at least enough of a sketch of how these mechanisms should work that we can be sure the basic headers will be compatible So goal is that the base protocol will be designed to require a direct connection for the exchange of large messages and will be extensible enough to support more complete solutions to this problem in future extensions. Even with these changes, there are some more elements of the base protocol that need to be cleared up, such as timeouts for large messages (even sent directly) and message fragmentation, but I think this captures the general intention of the changes. Bruce _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
