I largely agree with what you said in reply. Yes - I also agree that XEP-0301 will meet F.700 with 700 ms Transmission Interval if network delays are <300 ms. I also note that without KPI's, the Average delay is less - BUT the variability is Very High.
However, I think we are talking about some different things. I was talking about the need to quantify in some way the psychological impact of KPIs on the User Perception of Transmission Intervals - whatever they are set at. I am concerned that implementers, because they have little idea of the Impact of KPIs on Users, may GUESS that KPIs will give 'a bit of improvement' but assume that it is not worth them implementing KPIs. (We are all aware of the many announcements of 'big improvements' to some protocol or other which really mean 10% improvement if you are lucky. Quantification takes out the Guess-work.) Some quantification of the magnitude of the Improvement - one or two sentences - could indicate that there is a significant benefit to implementing KPIs - and it could allow longer Transmission Intervals which would reduce the <message/> stanzas/sec whilst keeping the User perception of delay within acceptable bounds. 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 12:02 PM, Mark Rejhon <marky...@gmail.com> wrote: > 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" <btdin...@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 <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 >>> >> >>
