[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

Gunnar Hellström gunnar.hellstrom at omnitor.se
Tue Jul 24 22:08:48 UTC 2012


Second set of comments. It seems that we would need to number the issues 
and follow them up separately.

On Mon, Jul 23, 2012 at 10:32 AM, Kevin Smith <kevin at kismith.co.uk 
<mailto:kevin at kismith.co.uk>> wrote:
6.1.4 - "it is acceptable for the transmission interval of <rtt/> to 
vary" - yet earlier there was a SHOULD saying it doesn't vary, wasn't
there?

On 2012-07-24 18:58, Mark Rejhon wrote:
>
>     On Tue, Jul 24, 2012 at 4:13 AM, Gunnar Hellström
>     <gunnar.hellstrom at omnitor.se <mailto:gunnar.hellstrom at omnitor.se>>
>     wrote:
>
>     <GH>I thought the "approximately" to mean something much more
>     close to 700 ms. I thought you wanted it just because of
>     granularity of timers and that there is no need to be very
>     precise. If you let it go down to 300 ms, you may get problems
>     with bandwidth and servers, if you let it go up over one seconds
>     you miss occasionally the usability goals for good real-time text
>     according to ITU-T F.700/F.703.
>     I do not usually regard 300 to be approximately 700. It would be
>     strange to need to put a figure on it, but it could be "The
>     interval should not vary more than 20%."
>
>
> Comments:
> -- Your interpretation is correct too.  "approximately" can mean 
> something much closer to 700ms.  The interpretation is quite flexible, 
> so there is a lot of interpretations.
> -- I wonder if you may have misinterpreted me.  The key word is 
> "average".  The math of (0.3 + 1.0 + 0.4 + 1.1) / 0.7 = an average of 
> 0.7.  Thus, this is acceptable, and no more harmful to XMPP servers 
> than (0.7 + 0.7 + 0.7 + 0.7) / 0.7 = average of 0.7 ....   Same 
> harmlessness for (1.4 + 0.0 + 1.4 + 0.0) = an average of 0.7.   
> Besides, network conditions sometimes forces these variabilities, anyway.
> -- If we needed to be fully technical about it, we could theoretically 
> mention an averaging window (I'd say, a window of approximately 5 
> seconds is quite reasonable.  For example, an average of 0.7 seconds 
> over the last 5 seconds).  But I don't think we need to be this strict 
> about intervals.  Again, the XMPP people are not the SIP people.
> -- It's worth mentioning it is harmless to XMPP servers to have an 
> instance of a coupling (i.e. 2 <message/> stanzas transmitted 
> simultaneously and almost simultaneously).  It happens all the time in 
> XMPP anyway, prescence updates, chat states, and short messages -- it 
> happens frequently, and it's not uncommon for clients to sometimes 
> occasionally send five stanzas (even ten) in less than one second (for 
> different purposes, like prescence updates, disco queries, chat state, 
> message being sent) -- unrelated to real-time text.  It is sustained 
> flood (a hundred of stanzas all at once) that starts becoming 
> unreasonable.
> -- The key word is "average", so it was not meant to suggest an 
> average of less than 300ms, even if pairs of stanzas might chunk 
> together to less than 300ms.
> -- I am pretty certain that even the XSF people agree with me here, 
> that they are not picky over 0.1 second differences, as long as the 
> average remains unaffected.
> -- XMPP is not strict-synchronous technology like SIP, where delays in 
> XMPP is just simply graceful degradation that is often not noticed in 
> instant messaging, while delays in SIP can kill a voice call.  Thus, 
> varabilities in intervals are not critical.   XMPP is a higher-level 
> protocol layer that does not specify timing tolerances.
> -- I think I will replace the word "approximately" with the word 
> "average", or say "the default average should be approximately..."
> -- In case you ask about interference with <w/> elements -- you can 
> use less Wait Intervals (<w/> elements) when the <rtt/> is buffered 
> for a shorter period and transmitted sooner, and more Wait Intervals 
> (<w/> elements) when the <rtt/> is buffered longer and transmitted 
> later.  It continues to lead to smooth playback at the recipient end.
> -- Network protection or congestion behaviours tend to generally come 
> ahead when there's a period of sustained rapid flow (i.e.100+ XMPP 
> stanzas all at once) -- which isn't what we're doing at all here. 
>  Even so, sometimes it's a way higher limit on a fast server in less 
> loaded conditions (i.e. 5000+ XMPP stanzas).  Or just simply 
> rate-limiting at weak triggers at 10 XMPP stanzas, etc.   So, that 
> occasional doubling to tripling up of stanzas is a non-issue (i.e. 2 
> or 3 stanzas sent consecutively at once)
>
> It is worth pointing out that some people outside of XMPP may be a 
> little nervous about timing of intervals, because of a large debate 
> about transmission intervals amongst the SIP people when standardizing 
> older real-time text technologies RFC2793 / RFC4103 / RFC5194 
>  (RFC2793 is 12 years old).  The nature of XMPP is not as synchronous 
> as SIP, and interval timing is less critical than it was for SIP. 
>  Historically, the XMPP people have not made a huge fuss about 0.1 
> second differences -- unlike the SIP people when the real-time text 
> RFC's were first standardized more than ten years ago.
>
> In summary, the good people at XSF may express concern about the 
> average interval itself ("I'm wondering if 0.7 second too frequent?"), 
> but I know they do not generally care about occasional doubling-up or 
> tripling-up of stanzas simultaneously (in the viewpoint of "bad, bad, 
> that fraction-second variability is bad, bad!" ... "bad, bad, that 
> quick pair of consecutive stanzas is bad, bad!") -- it happens anyway 
> in regular XMPP without this protocol -- especially in clients that 
> implements lots of XMPP protocols.   It's a high bandwidth / high 
> average rate that's more discouraged than random doubling-up of 
> stanzas sent less than 0.1 second apart.... I repeatedly brought up 
> this topic here in the mailing list (including dedicated threads!) and 
> it just confirms what is already known about XMPP's stance about 
> intervals.
>
> Opinions welcome from unbiased people who have not gone through the 
> experience of a fierce debate a decade ago -- regarding a more 
> synchronous technology -- during an era of lower bandwidth -- and 
> slower servers.  The 0.1 second variances doesn't matter here.
<GH2>This discussion is just about a discrepancy between 6.1.4, 4.1 and 4.4.
6.1.4 says " In addition, it is acceptable for the transmission interval 
of <rtt/> to vary, either intentionally for optimizations, or due to 
precision limitation."
4.1 says "The <rtt/> element is transmitted at regular intervals "
4.4 says "For the best balance between interoperability and usability, 
the default transmission interval of <rtt/> elements for a 
continuously-changing message SHOULD be approximately 0.7 second."

It looks most consistent for the logic to just delete "either 
intentionally for optimizations, or due" from 6.1.4.







>
>>                    Perhaps I could split it into a "5.1. Business
>>     Rules" section (ala XEP-0085) but I'm not sure that this is
>>     appropriate.
>>     Alternatively, I can add it as a "6. Business Rules" (bumping
>>     Implementation Notes as a section 7)
>>     Peter, David, et cetra from XSF, any comments?
>
<GH2>OK for inserting Business rules and moving most of 6 to it.
>
>     <GH>All of chapter 6 contains items that touch protocol, and here
>     and there contain rules. So, I think we can safely call all of 6
>     something else. I find "Business rules" a bit strange selection of
>     words for this technical area. How about "Application details".
>     Are there any habits in XSF already for such sections?
>
>
Section 6.6 of XMPP Author Guidelines recommend the phrase "Business 
Rules":
> http://xmpp.org/extensions/xep-0143.html
> Also, I doublechecked - google search of XMPP specs show it's common:
> https://www.google.ca/#hl=en&q=xmpp.org%2Fextensions+%22Business+Rules%22
>
> So, it seems the habit is frequently the name "Business Rules".   
> Renaming "Implementation Notes" won't solve the problem, because Kevin 
> wants me to bump it higher upwards in the specificatio. This would 
> almost certainly necessitate a new section between "5. Discovering 
> Support" and "6. Implementation Notes".   XEP-0085 uses "5.1 Business 
> Rules", as an example.
>
<GH2>OK, covered above.
>
>         [Change Made]
>         Beginning now says /"*It is possible for sender clients to*
>         implement [[[Message Reset]]] as the only method of
>         transmitting changes to a real-time message." /Although it
>         already explains why it's discouraged, I've now removed the
>         word "may" to reduce the permissive-sounding tone.
>
>     <GH>I earlier proposed another title for this section. Calling it
>     "Basic real-time text, it may attract interest from implementors.
>     Maybe "Using 'reset' for all transmissions.
>
>
> The attraction of interest doesn't seem harmful in this case because I 
> already point out the disadvantages and people can clearly see that it 
> could consume bandwidth -- it makes people realize that XEP-0301 is 
> quite flexible from basic real-time text all the way to complicated 
> real-time text.  XEP-0301 is one of the top 20 biggest biggest XEP's 
> (the top 5%) so this short mention of how tiny a subset of XEP-0301 
> can work (with certain disdvantages that make it unsuitable for many 
> purposes), is quite educational.
>
> -I think the title is good -- though I am open to changing the title, 
> but reasonbly self-explanatory titles are generally preferred (even to 
> people who don't know what a Message Reset is yet).  The Table of 
> Contents needs to be reasonably comfortable to read.  Comments from 
> others?
> -- In addition, I'm open to adding more text to discourage the usage 
> (than the edit I already did).  This is preferred over renaming this 
> section.  Comments from others?
>
>         [Comment]
>         6.4.4 is useful if it's not humans generating real-time text.
>          For example transcription bots, gateways, etc.  So it's quite
>         simple/useful to have append-only real-time text (and you can
>         still do key press intervals, if needed, unless you're
>         outputting fully-transcribed words one full word at a time)
>
>     <GH>I suggest to delete the second paragraph of 6.4.4. It tries to
>     reinstate the functionality you lost by following the simple rule
>     of the section, and ends up open ended if statements. I can
>     imagine other ways to solve the mid message editing, but I think
>     it is out of scope. By mentioning that you lose keypress intervals
>     you may also give the impression that that is for all of 6.4.4,
>     but it is only for that described method to do mid-message editing
>     anyway in a method intended to not have that functionality.
>
>
> A major implementer (>100 million users on their chat system) 
> specifically asked about this.
> It's using append-only real time text (with key press intervals) 
> during normal typing, but following "Basic Real-Time Text" whenever 
> doing mid-message editing.   I find that this is perfectly reasonable 
> use of XEP-0301, and the behaviour is compatible all the way to 
> version 0.0.2 of the spec -- it's just simply creative use of message 
> resets to simplify mid-message editing, without losing key press 
> intervals 99%+ of the time (Because 99%+ of the time, people will be 
> typing at the end of text instead of the middle of the message.).   
> You get almost the best of both worlds -- key press intervals, and 
> simpler sender implementation.   The disadvantages ONLY occur during 
> mid-message editing.
>
> As a result, I strongly believe it is not appropriate to delete this 
> paragraph, but it can be appropriate to rewrite this paragraph to be 
> more clearer.
>
<GH2>The specification begins to be overspecified with what you can do 
if you do not want to follow the main idea. You are right, you can do as 
the second paragraph of 6.4.4 says, but it has risks that it 
occasionally creates unfavorable user experience. I think you should 
leave to the creative reader to create such odd usage combinations of 
the protocol elements.

So, I still propose to delete the second paragraph of 6.4.4.
>
>         [Change Made]
>         /"This provides immunity to variable network conditions, since
>         the queueing action will smooth out incoming transmission
>         (e.g. receiving new <rtt/> while still processing a delayed
>         <rtt/>).
>         /Network issues can cause huge variability in transmission
>         interval.
>         -- The sender may be sending <rtt/> elements on a 0.7s, 0.7s,
>         0.7s, 0.7s, 0.7s
>         -- The recipient may be receiving <rtt/> elements
>         delayed 0.9s, 1.3s, 1.5s, 0.0s, 0.0s  (due to network conditions)
>         This results in stall-surge behaviours of real-time text that
>         need to be smoothed out during playback, for the best user
>         experience while preserving key press intervals.
>         [snip]
>
>     <GH>Yes, the speeding up sentence is very important. It is better
>     to skip displaying keypress intervals occasionally and get back to
>     acceptable latency (<2 seconds end to end ) if there has been a delay.
>
>
> Glad you agree.
>
>         [Change Made]
>         "In addition, it is best to process <w/> elements
>         asynchronously, to avoid interfering with client operation."
>         [snip]
>
>     <GH>This is a programming hint in the middle of protocol
>     description. It might be better to delete it. It should be basic
>     knowledge of communication programmers to not let the whole
>     process hang on a timer. I see a small risk that the words
>     "process asynchronously" are misunderstood for something complex
>     in the transmission. Or at least cause extra wondering time before
>     it is figured out that it is an internal hint.
>
>
> Good point.  Will await Kevin's response to the original email.
>
>     <GH>MUC support is important. It can be used as the multi-party
>     bridge for XEP-0301 in multi-party multimedia calls, where typing
>     and reading participants must have the same right to participate
>     in rapid exchange as the speaking participants.
>     In such situations it is mainly one speaker at a time that
>     transmits real-time text, so the load considerations are not
>     terrible, but are there.
>
>     People without rtt have a tendency to send short incomplete phrase
>     parts often to compensate for the lack of rtt, so in reality, rtt
>     will "only" increase the load by a factor of 4 or so. 
>
>
> Depends on implementation.  Don't forget to distinguish "Load Factor" 
> from "Message Rate Factor".
> A factor 4 is a pretty safe figure, but, it's risky to even mention 
> any figures, without citing a good paper first.
>
> Loading Factor: Server loading is not always linear with message rate. 
>  Sometimes adding an extra transaction only increases load factor 
> slightly.  (e.g. In a highly optimized server, 10 transactions in 10 
> seconds might only consume 10% or 25% more resources than 5 
> transactions in 10 seconds -- because of optimizations done for active 
> connections.)
>
> Message Rate Factor: For situations of 4 <rtt/> per message, the 
> transaction rate factor can potentially increase by less than 2, if 
> you slipstream <rtt/> into existing stanzas that are sent anyway (e.g. 
> XEP-0085 chat states), and also since in many XMPP implementations, 
> several other stanzas (e.g. prescence updates, queries, chat states, 
> disco, etc.).   Using WireShark / Ethereal snooping, I've seen 
> particularly chatty XMPP implementations that send more stanzas during 
> regular under-40-character message chatting -- than a very basic 
> implementation of XEP-0301.    So in certain situations, a basic 
> XEP-0301 implementation can actually have a lower stanza rate than a 
> very chatty non-XEP-0301 client that sends a lot of background 
> traffic.   (That's a funny situation, isn't it!)
>
> So, one has to calculate "how much additional load" that XEP-0301 
> contributes to:
> 1. The existing background traffic in an XMPP client
> 2. Of this existing background traffic, the opportunities to 
> slipstream <rtt/> into those (e.g. stanzas transmitting chat states)
> 3. Server optimizations that make an additional transaction 'less 
> expensive' than the previous (non-linear load scaling)
> 4. Some clients are more "chatty" than others in background traffic.
>
> So, there are situations where load factor could be well over 20x, but 
> there are situations where the load factor apparently is LESS than 1x 
> when compared to chatty implementations :-)
>
<GH2>And what is the conclusion then? I would not like to discourage 
from use in MUC.
>>
>>         [Comment]
>>         I made comments earlier.
>>         Even when senders send to the full JID, recipients can just
>>         process real-time messages based on bare JID.
>>         This makes it simpler for implementers of clients to
>>         implement only a single real-time message per chat window.
>>         It is a significant user interface complexity concern to gain
>>         the capability of multiple simultaneous real-time messages in
>>         the same chat window user interface.
>>         Also, it is intuitive behaviour because of "Keeping Real-Time
>>         Text Synchronized" so a simultaneous login user switching
>>         computers, the recipient would simply see their copy of the
>>         real-time message switch instantly from the
>>         partially-composed message from the old system to the
>>         partially-composed message from the active system.  (thanks
>>         to the Message Reset feature of "Keeping Real-Time Text
>>         Synchronized".   Even further enhanced if good resource
>>         locking is done, too.  This is acceptable UX behaviour, as a
>>         login is meant (in 99%+ of cases) to only have one typist.
>>
>> <GH>Just keep the last sentence and change to a should: "Clients 
>> should distinguish the <rtt/> streams (via full JID and/or via 
>> <thread/>) and keep multiple concurrent real-time messages in similar 
>> manner to Multi-User Chat 
>> <http://xmpp.org/extensions/xep-0301.html#multiuser_chat>."
>
> This sounds like a good suggestion, though I have to stay away from 
> RFC2119 normatives after section 5.  Unless I move MUC it to the new 
> "Business Rules" section, then the normatives are acceptable in a 
> "Business Rules" section, from my interpretation of XEP-0143.
> However, I'll wait for other comments in this regards, as I'm waiting 
> for comments to my response about bare JID handling and XEP-0301.
<GH2> I think it belongs to Business rules.
>
>         I've managed to reduce the size of Interoperability
>         Considerations significantly (to the best of my ability), but
>         there are several people including actual implementers
>         (outside the XMPP umbrella) that are demanding this text be
>         bigger than it is now.
>         [snip]
>
>     <GH>I think this section has a suitable size now. It is true that
>     we shall not dictate what to use on the SIP side, so your small
>     change is appropriate. We can describe what is available and
>     briefly some actions to do to interoperate with these
>     implementations. More details can go elsewhere.
>
>
> I now have a reference to the Real Time Text Taskforce (R3TF), so any 
> further Interop info can go there.  (And I encourage the creation of 
> interop specifications)
>
>
>         [Change Made] -- Good catch, I see the redundancy.
>         /"It is important for implementors to educate users about
>         real-time text"./
>
>     <GH>It is rather the application information that should make this
>     clear. We do not need to chase implementors out in the field to
>     become teachers.  how about: "It is important for application
>     information to educate users..."
>
>
> [Change Made]
> I've changed it to /"It is important for applications to educate users 
> of real-time text./
>
<GH2> Good
>
>         10.1 - I think a sensible Privacy note would be to make RTT
>         opt-in.
>
>         [Comment]
>         That depends on the market.  Mainstream client? (opt-in)
>          Accessibiltiy-market client? (opt-out)   Emergency mode?
>         I am in contact with different implementers who will pounce on
>         me if I suggest either direction (opt-in versus opt-out).
>
>     <GH>This is the natural text communication. In my view Opt-in is
>     not needed and not wanted, but I know others have different views.
>     Let it be out of scope for this protocol specification.
>
>
> I agree with Gunnar.
> Kevin suggests opt-in, Gunnar suggests opt-out.  Multiply these views 
> by a dozen happening in private discussions.  Discover a few gray 
> hairs on my scalp.  I see strong merits in these views.  (e.g. 
> emergency clients, accessibility clients, etc.)   The implementation 
> detail of opt-in versus opt-out is beyond scope of XEP-0301, except 
> making sure both sides interop with each other.
>
> In closing out a serious discussion, I humbly attempt at some relief 
> humor:
>
> <humor>
> Opt-in versus opt-out.
> So beyond scope.
> So beyond scope, it's on Mars.
> So beyond scope, it's a long time ago, in a galaxy far, far away.
> So beyond scope, it's a parallel universe, in a universe where physics 
> does not exist.
> Sides stronger than matter versus antimatter.
> Opt-in merges with opt-out.
> A warp core breach is in progress.
> Ejecting the warp core!
> </humor>
>
> Mark Rejhon
Thanks,
/Gunnar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120725/79f9960d/attachment.html>


More information about the Standards mailing list