[Standards] review of XEP-0301, sections 1-5

Mark Rejhon markybox at gmail.com
Sun Aug 19 02:02:11 UTC 2012


The use of key press intervals, at a 700ms transmission interval has
predictable lag: 700ms lag.

This produces the bottom floor for lag with key press intervals.  No
keypress is lagged by more than 700ms on a LAN connection on a fast local
XMPP server.  No further lag is added by software except by computer,
software and network performance.

We already meet ITU-T Rec F.700 with the key press intervals for the
definition of 'real-time' as long as no more than 300ms is added by network
and performance considerations.

The elimination of KPI only halves the average lag per keypress (350ms
average reduction of lag).

Why?  The first keypress of a 700ms interval is not delayed by key press
intervals, while the last key press is.  So average added lag caused by key
press interval is exactly half the transmission intervals.
On 2012-08-18 9:36 PM, "Barry Dingle" <btdingle at gmail.com> wrote:

> Good points Mark. Meeting F.700 real-time requirements is very desirable.
> They are based on human perception of what is real time - and on network
> Service Provider needs as well. However, F.700 does NOT consider any
> possible enhancements from 'client processing'.
>
> The inclusion of 'key press intervals' (KPI) actually changes the human
> perception of delay. (I and many others have been surprised at how
> effective it is.) So the end-to-end delay is not the only factor in user
> perception. There are some figures I have seen that indicate that the
> acceptable Transmission Interval with KPI's is *MUCH Higher* than
> Transmission Intervals without KPI's.( 700ms versus 300 ms comes to mind;
> what are the figures for longer Transmission Intervals?)
>
> So we really need a new version of F.700 (specifically an addition to
> Annex A.3 to provide a T3 delay that applies when 'key press intervals' or
> something similar are implemented. But getting an enhanced F.700 will take
> a long time - if the ITU-T ever does decide to update it. For XMPP
> purposes, *we can only assume that F.700 will NOT be updated*.
>
> Therefore we should include in XEP-0301 some form of *estimate of the
> improvement* that the proper use of KPI's provides so that implementers
> have an idea of the trade-off's that they need to consider when doing the
> inferior but 'less software intensive' smoothing options in XEP-0301.
>
> The 'improvement factor' does not have to be exact - and should be a bit
> on the conservative side. It would leave the trade-off to implementers.
> However, this ignores the fact that BOTH ends need to implement KPI's (<w/>
> is only Recommended).
>
> Another way to describe the improvement could be to have *TWO Recommended
> Transmission Intervals* - one with 'KPI support' and one without.
> However, this then raises the question of whether the protocol should *
> negotiate* the transmission interval based on the support for KPI's at
> BOTH ends.
>
> Is Transmission Interval negotiation getting too complicated for now?
>
> Do we just include a *one sentence/paragraph* about approximate
> qualitative improvement in user perception of delay when using KPI's at
> BOTH ends?   The paragraph could also mention that the extra contents per
> stanza when using KPI is compensated for by stanza's being sent at a lower
> rate. (This information could go in 6.1.2.)
>
> Cheers,
> /Barry
>
> Barry Dingle
> Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
> Fellow of University of Melbourne, Electrical and Electronic Eng.,
> Australia
> > Apple + Linux + Open Source software
>
>
> On Sun, Aug 19, 2012 at 1:44 AM, Mark Rejhon <markybox at gmail.com> wrote:
>
>> On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström
>> <gunnar.hellstrom at omnitor.se> wrote:
>> > On 2012-08-18 05:15, Mark Rejhon wrote:
>> >>
>> >> (for <t/>)
>> >> >and Basic Real-Time Text (whenever <e/> is otherwise needed).  A major
>> >> >potential implementer has indicated they prefer this method for
>> >> >simplicity (low CPU overhead compared to section 6.4.1 "Avoid Bursty
>> >> >Text Presentation").
>> >
>> > Mark, this is a side question, not influencing the <e/> discussion.
>> > What is your proposal to this potential major implementer to make
>> real-time
>> > text usable when only using 'reset' and not using <w/>.
>> >
>> > Do you recommend to use a shorter interval than 700 ms? The earlier
>> > documented usability limit is 500 ms. Above that, the users start
>> thinking
>> > jerkiness is unpleasant, and in reality 300 is experienced as more
>> pleasant
>> > than 500.
>> > -But we have said that 300 ms might cause too much load on servers or
>> > networks to be a universally used interval.
>> >
>> > Or do you recommend to use time smoothing (displaying received
>> characters
>> > progressively during the transmission interval ) instead of key-press
>> > intervals?
>> > -But you have said that time smoothing may be cpu consuming and is
>> > complicated to introduce on the receiving end in modern xml library
>> > environments.
>> >
>> > I hope they do not want to have annoyed users experiencing 700 ms jerks
>> in
>> > their text conversation.
>>
>> (This is talking about Transmission Intervals)
>> http://xmpp.org/extensions/xep-0301.html#transmission_interval
>>
>> I'm interested in hearing XSF's opinion about intervals.  They are a
>> compromise balance.
>> 700ms allows about 300ms of 'headroom' (network latency) to meet the 1
>> second (700+300 = 1000) end-to-end latency specified by ITU-T F.700
>> (section 2.1.2.1, IIRC)
>>
>> 700ms with key press intervals being preserved, often looks better
>> than 300ms without key press intervals.  They can also be roughly
>> similar (total) bandwidth, since key press intervals makes message
>> stanzas significantly larger.
>>
>> Now, I can say my tests have shown that 100ms intervals is nearly
>> always as reliable, but I've seen problems with a slow-performing XMPP
>> network when sending ten stanzas per second.  So that's probably too
>> low, but I definitely don't ban that because I only use "SHOULD"
>> terminology with the 700ms and the 300ms-1000ms ranges I've mentioned.
>>  So there's room for high-performance local XMPP networks with 0ms
>> intervals (e.g. instant transmit of every keypess), all the way to the
>> other gamut of slow low-rate 9600bps Iridium satellite transmission at
>> 2500ms interval (though that's more "NEAR real-time" not "true
>> real-time")
>>
>> All that said, I have no objection to implementers choosing to do
>> 500ms instead of 700ms, and I wouldn't even complain if somebody
>> decided to be daring and used 100ms by default for their network.
>> But should 500ms be the default?   I need many opinions before
>> changing 700 to 500.
>>
>> Mark Rejhon
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120818/024eb3e2/attachment.html>


More information about the Standards mailing list