On Sat, Apr 20, 2013 at 1:00 PM, Gunnar Hellstrom < [email protected]> wrote:
> On 2013-04-20 17:09, Christian Vogler wrote: > > Mark, > > can you describe exactly how the link to Section 6.5 solves the problem > of <w> interval backlog? The last version I saw made Section 6.5 look like > a suggestion (clients "can" ....), rather than something that is mandatory. > I might not be up to date with respect to the most recent changelog there - > but based on experience I now believe that implementing it has to be > mandatory, rather than optional. > > In order to avoid both jerky playout and excessive delay, I want to > propose the algorithm for catch up in 6.5 to be changed from > "Recipients can avoid excess lag by monitoring the queue for excess <w/> > action elements (e.g. unprocessed <w/> elements from two <rtt/> elements > ago) and then ignoring or shortening the intervals in <w/> elements." > > "Recipients can avoid excess lag by monitoring the queue for unprocessed > <w/> action elements from more than one <rtt> elements, and then shortening > the intervals in <w/> elements so that the sum equals the sum of <w> > elements in the latest <rtt> element." > Makes sense. I'm quite open to rewriting the section 6.5 (since that's an Implementation Note) to improve clarity. There is quite a lot of implementor flexibility to reduce XEP-0301 latency (none of which affects the XEP-0301 protocol in a way that holds up LAST CALL), and I do not wish to mandate one specific method of latency reduction. Clients can do any one of a variety of useful methods: (1) Upon receipt of the next <rtt/>, immediately flush out all unprocessed action elements ADVANTAGE: Programming simplicity. Guarantees you won't get a receiver-side backlog of <rtt/> DISADVANTAGE: Bursty output, whenever there's huge variances in ping (2) Upon receipt of excess total of <w/> elements (totalling two wait interval cycles), flush out all unprocessed action elements up to that point. ADVANTAGE: Guarantees you have a ceiling of two transmission interval cycles of delay. Less potential for bursty output. DISADVANTAGE: Slight increased programming complexity. More latency than approach (1) during large ping variances. (3) Accelerate playout of action elements if we have an excess of action elements ADVANTAGE: Eliminate bursty output, more fluid. DISADVANTAGE: May look unnatural when typing looks faster than a typist speed (e.g. which may happen during a disconnect-reconnect cycle, in clients that does the reconnects seamlessly -- e.g. wireless clients) Etc. There are other approaches. All the above will look completely normal whenever ping is steady and not varying. All of the above are all legitimate methods that any XEP-0301 implementor can choose to use, with no changes to protocol. However, a lot of us really don't want to mandate any one of the above as being the endorsed method. None of the above has anything to do with protocol-level / logical interoperability. That said, improved clarification to section 6.5 is welcome. That said, RFC2119 language is strictly being kept only to sections 4 "Protocol" and 5 "Determining Support" only (As it has for the last few XEP-0301 revision cycles), and the RFC2119 languages (MUST, SHOULD) is not used as part of Implementation Notes in XEP-0301. So it rightfully sounds as a suggestion. I'll tweak Section 6.5 as that is an Implementation Note. Mark Rejhon
