[Bug 54291] Add RequireOutOfBand to tubes

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=54291

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-08-31 10:03:42 UTC ---
Sjoerd and Rob had some suggestions for better naming, of which my favourite
was AvoidLowThroughput. Sjoerd pointed out that having a peer-to-peer
connection doesn't necessarily guarantee that it's actually any good;
conceptually, what we're after is "don't give me IBB or something similarly
rubbish, I want near-direct performance or an error".

One potential problem with the AvoidLowThroughput name is that it isn't obvious
whether AvoidLowThroughput=TRUE also avoids particularly high-latency
connections.

> + fail if no resources
> + supporting p2p tubes over ICE are found.

We don't want to require ICE specifically: we want to allow anything with
near-direct performance characteristics.

Maybe something like this:

    <p>If this property is TRUE in a request, the connection manager
      MUST only try transports that are expected to have high throughput
      and not be subject to usage limits beyond those of the underlying
      network connection, such as ICE. If no such transport
      is available, the request MUST fail with an error, typically NotCapable.
      Applications expecting to require a high-throughput connection
      SHOULD set this property to TRUE in their channel requests.</p>

    <p>If FALSE or omitted from the request, the chosen transport MAY
      have lower performance or be subject to rate-limiting or usage limits
      imposed by the IM server.</p>

    <tp:rationale>
      <p>On XMPP, Tubes can either be transported in-band through the
        server, or out-of-band. In-band data is subject to significant
        rate-limiting by the IM server, and sending too much in-band
        data can result in disconnection.</p>

      <p>For high-throughput applications, out-of-band Tubes are
        sufficient, but trying to use in-band data would be futile;
        it is better that a request to do so fails early, rather than
        sending bulk data in-band and only detecting that there is a
        problem when rate-limiting occurs.</p>
    </tp:rationale>

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.