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 <marky...@gmail.com> wrote: > On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström > <gunnar.hellst...@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 >
