On Sat, Nov 8, 2008 at 12:02 PM, Henning Schulzrinne <[EMAIL PROTECTED]> wrote: > > On Nov 4, 2008, at 3:57 PM, Bruce Lowekamp wrote: > >> 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. > > This assumes that there is only a single "link" between nodes. > >> >> >> Solving this properly is likely to be quite complicated. Since our >> primary usage requires only the exchange of URIs and certificates, the > > This isn't quite true. Even for the SIP usage, we'll have to worry about > voicemail messages, for example.
The SIP usage does not contain the word "voicemail." While I would love to see a draft proposing how to manage voicemail, there is not one at present. There are certainly some deployments that would be incomplete without a way of storing voicemail in the overlay, but there are also lots that have other ways to handle voicemail. I don't know if it's even true that a majority of deployments is likely to need or want voicemail in the overlay. > >> >> 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. > > I don't think that's helpful. For a relatively low-usage overlay or an > overlay running in a single data center or LAN, blocking won't matter even > with a single logical link, so I see no reason that an implementation > (rather than an instance) restrict the message size. > > I think it's important to distinguish between implementation limits (which > should be as close to the maximum given by length fields) and the policy > enforced for a specific overlay instance. I'm unclear what you're objecting to. > >> >> - 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 > > It should support the use of multiple links between nodes. I don't see any > great difficulty in allowing an implementation to open multiple connections > to another node. Whether to actually do this is then a policy decision. > First, I think the udp link protocol will have problems well before that. Second, for stream-oriented transports, I'm not sure that the draft currently prohibits multiple connections between peers. I'm not convinced it has enough support to make it work (and I would really not want to complicate it to add this feature), but I don't see why it wouldn't, offhand. >> >> - 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. > > Timeouts are going to be challenging no matter what. Even a small message > may take several seconds if links are crappy or the overlay is large. > (Somebody mentioned that search times in existing overlays, such as Azereus, > can routinely exceed 10 seconds and call setup latencies in Skype are pretty > long.) > > I suspect we'll need to recommend a more-or-less random value and > high-performance implementations will need to implement algorithms to tune > the timeout based on the measured properties of the overlay. Unfortunately, > time outs will matter mostly in less-than-ideal networks, rather than a data > center LAN. > I agree. I'm not convinced that the hard-coded 3 second timeout in 5.1.1 is what we want regardless of the large message issue. Bruce > >> >> >> 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
