On Jun 27, 2012, at 12:25 AM, Mark Rejhon wrote: > On Wed, Jun 27, 2012 at 2:44 AM, Kurt Zeilenga <[email protected]> > wrote: > On Jun 26, 2012, at 5:08 PM, Mark Rejhon wrote: > > Computers, networks, encryption is gradually becoming faster, and even > > stanza-level encryption for RTT > > Maybe one day we'll have virtually unlimited bandwidth everywhere... but > that's simply not the case today and likely won't be the universally case for > many decades (if ever). > > Even fast typing over real-time text, is still rate-limited to 1 stanza every > interval (such as 700ms or 1 second)
It's not how slow or fast the user types, it's how many RTTs stanzas are set in addition to the IM stanzas as seen on the XMPP network in total. If we assume every user has this extension enabled (which is the worse case, I believe) and is doing stanza level encryption, every RTT stanza added per IM stanza is one more fold increase in the bandwidth over stanza-level encrypted IM without RTT. The number of RTTs per IM likely depends on many factors, but I'm roughly guessing there's somewhere between 1 and 10 RTTs per IM stanza. Even at 1, we're basically doubling of the bandwidth demand. There's nothing marginal about such increases in bandwidth. > Multiple keypresses gets put into the same stanza if multiple keypresses in > one interval cycle. > Stanza level encryption performance is sufficient to support that, even on > smartphone CPU's today. I'm actually assuming CPUs can keep up. Even if they couldn't, that won't necessarily reduce the number of RTT stanzas on the XMPP network as they are likely to be send as produced. > > In borderline situations, you could adjust transmission intervals to violate > the recommended range 0.3s-1.0s (I only made that range a 'SHOULD') -- such > as transmitting real-time text at 2 second intervals instead. You? as in the user? User's don't know what's wrong, or how to fix it. Hell, they are likely to decrease the interval in hopes of getting an unfair amount of the available bandwidth. True congestion control should not be user driven, it should be code driven, based on feedback from the network. It should be designed to promote 'fair' allocation of bandwidth and congestion pain. > There would be a 2 second lag in typing and it would not comply with ITU-T > F.703, but near-real-time-text ends up being more usable than line-by-line > mode. Such situations where degraded near-real-time XEP-0301 is necessary is > rare, but I left wiggle room in XEP-0301 to use long intervals -- i.e. ultra > narrowband networks or extreme congestion (i.e. Iridium satellite style, > Mobitex style, overloaded GPRS, rural dialup, etc.) Try XMPP over HF radio some time. -- Kurt
