On Wed, Jun 27, 2012 at 8:55 AM, Kurt Zeilenga <[email protected]>wrote:
> > 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) > We need to distinguish "extension enabled" from "extension active". A chat client can advertise that it has audio/video support, but keep it inactive until initiated by the user. When RTT is added to a mass-market client (note: AOL's AIM has real-time text already) it would be something that can be initiated by the user, such as via a button, i.e. containing the International RTT symbol -- www.fasttext.org It would be a very gradual process, very few RTT users at first (first in slowly-increasing open source programs before it reaches a popular brand of instant message program), so the XMPP network has many years to scale/adjust to the needs. It's already scaled to meet the needs of in-band file and avatar-image transfers, for example. RTT penetration into mainstream clients is envisioned as a 10-year process. During this time, most of these software will do stream-level encryption instead of stanza-level encryption, so combined with the gradual scaling, it shouldn't be a big enough concern to mention in the spec about recommending turning off RTT during stanza level encryption. > 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. > Given average instant message lengths of 40 characters, that sounds accurate. Even with many layers of bubble-wrapping, it's still far less bandwidth than video. You can also 'fold' the real-time text in other stanzas you normally send, such as Chat States, so subtract about 1 or 2 the total increase. > > 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. > No, no -- it's a software decision. When I said "you", I meant the developer. Apologies for not being clear. Software be designed to automatically adjust the transmission interval to automatically adapt to situations such as bandwidth, congestion, decide to do flow control (acknowledgements), etc. You can do fancy flow control on real-time text to run reduced-rate real-time text on an overloaded server. So it's no longer the end of the world. I even already mention this in section 10.2 Congestion Considerations: http://xmpp.org/extensions/xep-0301.html#congestion_considerations This should cover the situation when part of the chain of the real-time text is 'expensive' (i.e. stanza level encryption slowing down real time text) 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. > That's what I said. :-) Sincerely, Mark Rejhon
