Gunnar has good observations, and arguments about removing negotiation of interval. However, some importantant additions to Gunnar observations.
I did a test with Gunnar was with an older version of my client running on my slowest performing machine, running over a cellular link. In this situation, I pushed the limits and it started suffering at anything less than 500ms. However, the new version of my software renders text about 10 times faster. I also want to point out: (1) There are use cases that warrant less than 500ms interval. Examples: I have a same-room chat system, and an upcoming LAN based product that I may use this technology in, that requires less than 500ms. Although I don't want to go into more details, I should note that iPhones and Blackberries running on WiFi become wireless keyboards for a shared big screen chat system on a projector or HDTV. In this case, even 500ms becomes distracting. Also, an in-game chat system or intranet chat system, would be more optimized if running at shorter intervals than 500ms. Even AOL AIM Real Time Text uses an approximately 250ms interval. (2) There are cases that warrant more than 2000ms interval. Examples: 9.6 Kbps iridium link, future multiuser chat extension when everyone suddenly starts typing at same time (otherwise you'd get 20 to 50 XMPP packets per second of a sudden, to EACH person in chat). Also, delay codes have a major impact on the quality of conversation (inter-keypress delays, natural typing). Conversations with delay codes looked better at 1000-2000ms (1-2 seconds), than WITHOUT delay codes at 500ms interval. Different people have different preferences and tolerances about interval. I did, however, find in my testing that several people even preferred 3000ms with interkey delays being played back, versus 1000ms suddenly bursted out every second without interkey delays! Not everyone, but at least a few of us liked the natural typing so much that we could tolerate a much bigger lag in the conversation, if the typing was played out naturally in original typing delays. I am not advocating large intervals, but I need to point this observation out, and also that use cases do indeed exist. Then again, we necessarily don't care about Internet interoperability with proprietary same-room systems, or similiar, and we are for now removing group chat extension. Thus, it may be more feasible now to agree on a standard interval, provided it becomes part of the specification rather than an implementation note, due to interoperability concerns of letting programmers decide on their own interval value. Bottom line: I'd still like to at least transmit a client's own preferred interval, even if it's not negotiated. That way, respectfully well-programmed software can optionally throttle back for other software that indicated a preferred longer interval. Question is, what would be the simplest way, and also future proof, to advertise a preferred interval? Feature negotiate, disco, or caps? Mark Rejhon 2011/3/4 Gunnar Hellström <[email protected]>: > Yes, we had a lot of discussions about transmission intervals before the > draft was sent to XMPP. > And we many times concluded that the default interval should be one second. > > The more I see of efforts to squeeze the intervals to short times that will > cause problems in servers and narrow connections, the more I feel that we > should just fix the interval to one second. ( or possibly 500 ms ). > > We should view the interval as a sampling interval equally how audio codec > have. Most of them have fixed intervals or a couple of intervals in similar > range to select from. We should be able to fix it here as well. > > With Natural Typing, the smooth flow is achieved at any transmission > interval. > > So, it is only a balance between conversation usability regarding latency, > and the network and server load. > > Checking with users have resulted in the knowledge that for typed > conversations, problems start to appear if the end-to-end latency is over 2 > seconds, and conversation starts to break down with latencies above 3 > seconds. > > In typed conversations, it is not noticable if you have 500 ms latency or 1 > second latency. But we discussed that for captioning on the fly, there may > be already so much latency implied by the captioning technology that a gain > of 500 ms may be important for usability. > > So, I would say that the choice should be between 500ms and one second. > > More destroys conversation usability. Less is not needed and risks to cause > congestion. > > > This is easier to judge after you have tried it with the demo. > > Can we settle on one of these two alternatives and skip the negotiation of > this factor? > > > Gunnar > > > > > > > > ___________________________________________________ > Gunnar Hellström > Omnitor > [email protected] > +46708204288 > > > Mark Rejhon skrev 2011-03-04 19:27: >> >> All: >> My software is available for download (in binary format for now), >> compiled from C# on Windows. (Will be ported to Mono later for Mac >> and Linux). It uses the depreciated 0.0.1 spec, sans feature >> negotiation, in case anyone wants to try XMPP Real Time Text in an >> experimential alpha manner. >> >> http://www.realjabber.com/RealJabber_v0.0.1.zip >> >>> Imagine a satellite communications device (with >>> interval set to 2000ms ) connecting to someone else on a high >>> performance network (with interval set to 250ms). Then we now have an >>> interoperability problem. Even in tests, I ran into issues using >>> LAN-optimized intervals when running on a netbook running over an EDGE >>> data connection. This is amplified even further when using even worse >>> connections such as satellite or dial-up. >> >> I now think I need to expand on this paragraph about intervals. >> (Intervals of how often to send<rtt> elements) >> >> Interoperability problem caused by latencies can be caused by >> overwhelming the network traffic of bandwidth-limited devices like >> dial-up. XMPP Real Time Text can squeeze over dial-up, but can hit >> some limits especially if there's lots of other XMPP traffic >> (prescence stanzas on a big contact list, etc). Highly-shared >> satellite connections such as USA DirectPC and WildBlue go slower than >> dialup speeds, especially during peak periods. They have the addition >> of massive ping variability (fluctuations of over 1000ms) during peak >> periods. Cellular phone connections in poor reception areas (1 bar) >> can go slower than dialup speeds. Or when it's downloading things >> like a mobile email file attachment while you're chatting in another >> window (i.e. Android devices with multitasking). Even on my netbook >> test on a cellular connection, I was able to, from a remote XMPP >> client (set to very short 50ms and 100ms interval), overwhelm the >> netbook's chat application. >> >> So for maximized interoperability, software developers shouldn't have >> full freedom to choose just about any interval, and that is why we >> came up with a baseline recommendation of 1 second interval to cover >> the vast majority (albiet not all) of uses cases. It worked fine on >> all my use cases that didn't require latencies to be faster than 1 >> second. In my personal testing I actually preferred setting the >> interval to 300 or 500 milliseconds for desktop-to-desktop Internet >> communications. >> >> Related consideration: XMPP RTT is a potential channel of "Denial of >> Service" by flooding. But anybody can flood an XMPP server anyway, >> without needing the RTT spec. >> >> There was a lot of debate with the RealTimeText.org people about >> intervals. I feel that at the absolute minimum, a communicatable >> negotiable interval is absolutely necessary (the two clients >> connecting would simply choose the bigger of two intervals). >> >> Sincerely, >> Mark Rejhon >
