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.
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.
- 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.
- 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.
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
