> For a cellphone scenario, it may be worth considering the impact of falling > back to 2G coverage (e.g. increased delay/lower bandwidth). For example, > on 2G networks with inappropriately high buffering I have measured roundtrip > times as high as 3000 ms. Areas with 2G-only coverage are thankfully > growing less and less prevalent, but it is possible to encounter an > emergency in the middle of nowhere.
Normally, I find 3000ms intervals on GPRS networks is not a problem for XEP-0301, as I have already tested XEP-0301 over GPRS and over satellite. You can also use XMPP stream compression. There are extenuating situations, however. XEP-0301 has section 10.2 that suggests you can dynamically lengthen the transmission interval in order to survive extreme conditions like those you described. (i.e. 2,000 or 3,000ms). Please note that this is no longer really "REAL-time text" (it's only near-real time). That said, the existing XEP-0301 spec does not ban this practice, since 1 second is a "RECOMMENDED" guideline (not a "REQUIRED"). I only see this ever being needed in TWO very, very, exceptional cases: (1) Section 10.2 of the specification, "congestion considerations" where it's absolutely necessary to preserve the integrity of the conversation, due to various things such as bandwidth limits, performance limits, overloaded network/server, message-rate limits, extreme latency, etc. (2) Groupchat when everybody starts typing at the same time -- imagine everybody suddenly typing at the same time. Bandwidth and message rate spikes. Basically, I see it being useful only as a "last-resort" operation that's only done temporarily, before falling back to a default of 1 second transmission interval. It'd even work over Iridium satellite 9.6 Kbps connection, if need be... (probably the worst-case scenario). XMPP stream compression can also be used if the client and the server supports it, to save bandwidth as well, covered by other XEP's. The existing specification already has flexibility to cover these use cases: - One suggestion is to follow section 10.2 "congestion considerations" in the existing spec. - Dynamically adjust transmission interval, if _absolutely_ necessary to maintain integrity of XEP-0301 - Eventually if transmission interval is infinite, it's essentially equivalent to RTT turned off. - Use XMPP stream compression (XEP-0138, XEP-0229) to get huge bandwidth savings. (more than enough to keep RTT+NT even on a GPRS connection, even if the 1000ms interval is being chunked up/blocked up by the TCP/IP network into longer-interval bursts) - If bandwidth budget is very, very, very tight, it is possible for a specially written client to dynamically disable/enable natural typing (transmission of W interval elements), since it saves roughly 50-80% bandwidth when this is done; - It is important to note that if everybody suddenly types in groupchat, real time text bandwidth and packet rate dramatically spikes. (Imagine a big chat channel, 10 people start typing at the same time, the packet rate and bandwidth goes up 10x suddenly - i.e. 10 XMPP messages per second to everybody). In these situations, a message rate protection algorithm can be used, i.e. temporarily adjust interval longer if more than a few people are typing at the same time, until the groupchat quiets down. This is documented as a suggestion at http://www.marky.com/realjabber/XMPP-RTT-Supplement_2011-06-17.pdf (linked from www.realjabber.org) User experience will be severely degraded if you disable keypress interval encoding (W intervals) and/or if the interval is also lengthened. Even more especially if both is done. The use of shorter transmission intervals (300ms) helps, but it eliminates the bandwidth savings. The use of client-side text-smoothing helps, but it adds programming complexity for some people. Please be noted that the definition of "real-time" becomes inaccurate when we are talking human-noticeably long intervals like greater than 1 second. That said, the XEP-0301 protocol can be used at infrequent intervals in very, very, very exceptional special-use cases. I note that there has been significant internal debate in the past, within realtimetext.org (and some others) about what intervals meet the "real-time text" definition. Thanks! Mark Rejhon
