On 2013-04-19 00:39, Mark Rejhon wrote:
Gunnar, see the bottom of this message for a positive surprise....
Thank you for the honour, much appreciated to be even more part of this
important improvement of communication opportunities.
Firstly, I want to stress the importance of minimum changes.
I already privately emailed to XSF team and would prefer to submit
Version 0.9 with *almost NO CHANGE*.
Submitting 0.9 with many changes will automatically break my promise
and *will reduce the likelihood of last call approval.*
Agreed. The new items I included are results of a review. I wanted to
report them, but I agree that they are of a kind and on a level that can
be left without action.
I dont like saving things for a 2014 update. It is so much harder to get
a good effect of additions to a protocol when you already have an
installed park. But we can after discussion deem some not sufficiently
important to allow modification of the document now, or not mature enough.
On Thu, Apr 18, 2013 at 5:53 PM, Gunnar Hellstrom
<[email protected] <mailto:[email protected]>> wrote:
7.
Section 4.2.1 or 4.3 last bullet.
Insert:
"NOTE: Wrap-around may occur when incrementing <seq/> if the
randomly selected start value was close to the upper border of
<seq/>. "
NOT DONE
I am against adding too much text about seq without removing other
text about seq *in the "Protocol" section*. I think we already talk
too much about trivial seq issues right now as-is. One idea is that I
can delete most of the seq text and create a much bigger seq section
in the "*Implementation Notes*" section. The simple sentence about
the 31-bit bounds is currently sufficient (maybe a minor sentence
tweak if necessary), we know that properly following "*Keeping
Real-Time Text Synchronized*" indicates clients MUST not assume
incrementing seq values will always happen, so it already successfully
catches seq going backwards in time, which is exactly the wraparound
condition too, unless both ends do the wrap properly.
In addition to my preference, XSF has already complained that we are
already too much like a lower-layer protocol. Expanding the talk
about *seq* is against this goal, especially as the safeguards are
already sufficient now, in my opinion.
The only acceptable reason to not put this in is that we agree that
programmers are so well aware of handling incrementing sequence numbers
with upper bounds and risk for wrap around that it is safe to not
mention the risk.
The reasoning that if handling wrap around is wrongly programmed, then
it only halts presentation of text until the message is complete or a
new REFRESH is received is not sufficient reasoning for not entering the
note.
So, what is the habit in this environment? Do we trust programmers to
remember the wrap-around case? If so, we may leave it out.
Please do not change and move text just because of this. It is only a
one line note I ask for.
9.
Section 4.6.3.3 Insert
"Recipients SHALL avoid excess lag by monitoring the queue for
excess <w/> action elements (e.g. unprocessed <w/> elements from
two <rtt/> elements ago) and then ignoring or shortening the
intervals from the <w/> elements. This allows lagged real-time
text to "catch up" quickly."
( consider removing or reword the similar sentence from 6.5 so
that we do not have repetitions )
NOT DONE
*DONE (indirectly)*
What I did was simply make 4.6.3.3 link to section 6.5.
I did the change in a different way. It's a good change. It is not
an interoperability issue that belongs in the Protocol section (*I am
_extremely_ adamant to keep Section 4 as compact as I can, and
additionally also have been previously told by XSF to also keep
Section 4 "Protocol" as simple as possible.*).
This is an important performance issue. If the means for catch up
described in 6.5 are not implemented, then delay of one <rtt/> message
will proliferate through a complete sequence of continous typing. Since
chapter 6 is not supposed to have SHALLs, I suggested to move this to
chapter 4.
But of course, chapter 6 contains a lot of good advice that we can
expect implementors to follow. So if you have put in a pointer from
4.6.3.3 to 6.5 and sharpened up the wording in 6.5 it can be sufficient.
The actions against proliferating delays described in 6.5 should in fact
be developed into a smooth adaptive jitter buffer algorithm, that
results in low delays and small jerkiness at late delivery of an <rtt/>
element, rather than a constant longer delay and always true
reproduction of key press intervals. That can be done within the frames
allowed by 6.5.
In summary: I accept your proposal.
10. Is there a risk for delay introduced in the description of <w/> ?
In beginning of 4.6.3.3 it is said that <w/> represent time
between key presses.
in 6.1.2 it says that <w/> represent wait between Action
Elements <http://xmpp.org/extensions/xep-0301.html#action_elements>.
Assuming that key presses are momentary, but it takes some
milliseconds to complete some action elements this will introduce
on the receiving side a sum of waits and action element
performance time that is more than the transmission interval.
Thus, delays will be introduced during times of continous typing.
Do we need to be more concise with what time <w/> represents?
Should 6.1.2 be modified to say Is it "wait from end of latest
wait" or "wait from beginning of execution of latest action element ?
*WORTHY (IF REWORDED) -- BUT POSTPONE TO 2014*
This is good discussion (and see below for more info about how Chris
and I do it), but this can be a Year 2014 discussion if it shows to be
a performance concern. But it isn't the cause of lag in current
XEP-0301 implementations. More urgently is solving the problem of
mishandling late <rtt> arrivals -- which is the *chief cause of the
lag in both of our XEP-0301 implementations.* This is stuff that the
spec needs to improve, but the talk here is an unnecessary
complication / sidetrack. Computers/phones are fast enough that doing
either approach would work good enough, provided there was code to
handle the chief cause of lag (<rtt> backlog)
In 4.6.6.3, it says:
"Wait n milliseconds before processing the next action element."
proposed to be changed to:
"Wait until n milliseconds after end of latest wait, before
processing the next action element, or if this is the first <w/>
in the current real-time message, then wait until n milliseconds
after beginning handling presentation of that real-time message ."
*WORTHY (IF REWORDED) -- BUT POSTPONE TO 2014*
This turns an easy-to-read sentence into a hard sentence.
More bugs will occur with your sentence than with mine, purely because
your sentence is hard to read.
Besides, it's not currently the cause of lag in RealJabber or Chris'
software.
The cause of lag is from a backlog of <rtt> elements.
This is not an urgent matter of concern.
Error margin of different <w> handling is extremely small, and
human-perceptible differences will only be noticed slow machines (e.g.
netbooks) and <rtt> catchup handling can handle this anyway.
Don't let us mix this issue with what might have been observed in
current implementations. It is a small logic glitch and was a pure
finding from review.
I agree that my wording got clumsy in order to take care of both <w> in
the beginning of an <rtt> element and further in.
One case when the interpretation of <w> could matter is in a slow device
getting a huge REFRESH with some added recent typing including a <w>
appended in the same <rtt>.
According to sender logic, the <w> represents the time from the last
keypress before the REFRESH to the one appended in the REFRESH.
According to the receiver logic, the <w> is time between action
elements. The waiting time shall start when the real-time buffer is
reset and the reestablishment of the old text is done and displayed. In
continuous typing e.g. in conference transcription, this can be many
thousands of characters that need to be placed into a display buffer
etc, so it may very well build up to many milliseconds addition to the
delay. Without the hint for catchup logic in 6.5 obeyed, there could be
a continuous addition to the delay by coming REFRESHs.
But, I agree that making a stronger recommendation for catch up logic
in 4.6.3.3 and 6.5 will help against this effect and other glitches. The
talk about precision in other sections ( 4.6.3.3 and 6.1.4 ) might also
contribute to delays if there is no catch up logic.
And, by the way, this is only a risk during constant typing without
pauses longer than the transmission interval (usually 700 ms ). So it is
odd cases we are talking about.
Yes, I agree, we can leave this whole issue ( 10 ) without action.
In 6.1.2 it says:
" This is achieved using Element <w/> – Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>
between other Action Elements
<http://xmpp.org/extensions/xep-0301.html#action_elements>. Sender
clients can transmit the length of pauses between key presses,"
proposed new wording:
"This is achieved using Element <w/> – Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>
from previous <w/> or beginning of the current <rtt/> element.
Sender clients can transmit the length of pauses between key presses,"
*WORTHY -- BUT POSTPONE TO 2014*
It makes a lot of sense but I'm going to postpone this change for now,
because of unanticipated side effects of minor wording tweaks.
Both me and Chris treat <w> intervals accumulating on a system time
since the beginning of <rtt>, so slow local performance doesn't cause
<w> to
The cause of <rtt> lag is chiefly caused by late delivery of <rtt>.
These wording changes WILL NOT solve the lag in either RealJabber or
the Gallaudet RTT client.
I deem this a bit of a sidetrack / red herring discussion.
FOR DISCUSSION
11. Should we improve chances of smooth and low latency playout by
putting XEP-0203 timestamps on the messages as a guide to when it
should be played out.
E.g. by inserting this sentence in 6.1.2.
"For more accurate timing of beginning of playout of each <rtt/>
element, it is recommended to insert a time stamp on the <rtt/>
elements by use of XEP-0203 time stamping, and on the receiving
side let this value control when playout of the element starts
rather than timing it only from the <w/> elements throughout the
whole real-time message."
Then, a reference to XEP-0203 needs to be added as well.
FOR DISCUSSION
*WORTHY -- BUT POSTPONE TO 2014*
I like timestamps, but this is an obvious "cart before the horse"
situation.
I think this can be a Year 2014 discussion. It doesn't belong in
XEP-0301 right now.
Chris can easily experiment with this, without it requiring to be part
of XEP-0301.
It is a permissible stage of discussion for later into the DRAFT
stage, after there's already fully functional XEP-0203 + XEP-0301
implementations.
Reading XMPP's website, this is an obvious permissible change during
DRAFT.
There is potential side effects with timestamps.
Sending intentionally inaccurate timestamps create a potential
security issue / DDoS.
Also, timestamps could diverge if one computer changes system clock
(e.g. automatic synchronization with time server).
There are MANY nasty bugs that can be introduced with timestamps.
The KISS principle applies here.
There are other simpler solutions (other than timestamps) to reducing
XEP-0301 lag.
I rather see people create XEP-0203 implementations with XEP-0301,
before I mention XEP-0203 in XEP-0301
Also, the reference list in XEP-0301 already refers to too many other
XEP standards, giving the impression that XEP-0301 is more complicated
than it really is.
Yes, I like timestamps, but this isn't a LAST CALL showstopper. It
can be a Year 2014 discussion.
I already announced to the XSF team and would prefer to submit Version
0.9 with *almost NO CHANGE*.
Submitting 0.9 with many changes will automatically break my promise
and *will reduce the likelihood of last call approval.*
OK, go without it and introduce agressive adaptive jitter buffer
handling instead.
That said, I did hereby grant Gunnar Helstrom co-authorshop. I have
sensed a strong agreement with R3TF, despite my reluctance.
Congratulations, Gunnar, for becoming an official co-author -- it
does seem that you have rightfully met the requirements of
co-authorship under significant-contributer criteria. It does not
change my reluctance, as a main author, to support unnecessary/trivial
changes to XEP-0301 that is already adequately covered by the standard
or elsewhere.
Thanks a lot.
And thanks for a good discussion on the review findings. We are clearly
down to issues where it would be better to take it through last call.
/Gunnar
Mark Rejhon
