Re: [AVT] WG last call: text/red and RFC2793bis

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi Gunnar,

I have some comments:

Gunnar Hellstrom wrote:

[snip]

> 3. Section 4.2. transmission of old redundant data.
> Change rule about redundant data older than 16383 ticks. Include them,
> but set the
> timestamp offset to hex 3FFF. We never used the timestamp of text for
> anything. The
> receiver may decide if it is still appropriate to present the text. This
> new strategy
> simplifies logic for detection of loss, and avoiding false detection of
> loss.
It might look fine, doing what you proposed. However I see a few 
problems, that you will need to verify that you have thought of:

A. If multiple text blocks fall outside of the 16383 ticks, then you 
will recover multiple text blocks with equal timestamp. That violates 
one of your must.

B. How will old implementations react to this change? According to the 
old draft, a implementation may very well use the timestamp to check if 
the text block is the same as a previous one. Thus I think this change 
has interoperability issues.

[snip]
> 9 Last example in sec 7.2. The text says that there are two levels of
> redundant info in
> the example, but the figure only shows one redundant header. Insert one
> more.
This is in fact not an error, according to your own rules, if one reads 
the text completely:
  "As a follow-on to the previous example, the example below shows
   the next RTP packet in the sequence which does contain a new real
   T140block when using the audio/t140 payload format.  This
   example has 2 levels of redundancy and one primary data block.
   Since the previous primary block was empty, no redundant data
   is included for that block.  This is because when using the
   audio/t140 payload format, any previously transmitted "empty"
   T140blocks are NOT included as redundant data in subsequent
   packets."

You get the explanation in the last sentence. If it is desired to think 
of non sent block as impacting redundancy or not is another question. 
You will have to consider if it is more logical to repeat the same 
packet more than once, letting the receiver use the T140block counter to 
detect this, or in fact move on and include the empty blocks in the shift.

> 10 Section 3.2. T140block counter initialized to zero is a security
> weakness.
> We got a comment that it opens to security attacks to specify that the
> t140block counter
> shall begin with the value zero. This value was selected in order to be
> able to detect
> loss of the first block. In T.140, there is a requirement that the
> session shall start
> with a Unicode synchronization character. Even if there is no
> instruction today in T.140
> to indicate that the synch character is missing, applications can do so.
>
> However, the counter is a field in the payload, and it is common to have
> fixed patterns,
> like start-of-picture, start-of-block etc. in the payloads.
>
> We can change the text to require that the t140block counter shall start
> with a random
> value, and hint that upper layers should indicate loss of the synch
> character.
>
> I would like a second opinion on the importance of avoiding initial zero
> value on
> t140block counter before we do this change.
This depends on the cipher used when performing the encryption. For 
example in SRTP the ciphers defined for usage, all have the property of 
being resistant to known plain text attacks. I totally agree with the 
sentence in SRTP RFC 3711, section 9.3:

   As some RTP packet could contain highly predictable data, e.g., SID,
   it is important to use a cipher designed to resist known plain text
   attacks (which is the current practice).

An older cipher may not have this property. Which is likely based on the 
random tag for RTCP, and other things in RTP. However I think this 
property is necessary for any cipher being used with RTP. Because it is 
predictable to a large extent. Therefore any cipher not having this 
property should be replaced. And I don't see that RFC 2793bis makes this 
worse. I hope that any security expert will correct me if what I write 
is wrong.

Therefore I think you will be safe to define it as starting a 0. However 
in certain applications, for example multiparty sessions, the start at 0 
will give very little information, e.g. for late joiners. Basically it 
could only be used to count how many text blocks a certain user has 
sent. Thus I don't see any real gain of starting at 0.

> 11. Find another solution for loss detection in audio/t140 than
> introducing the t140block
> counter.
> We had discussions on ways to avoid using the t140block counter for
> audio/t140 in order to
> save bits and make the two formats more equal. Methods were proposed
> based on the M-bit
> and detection of empty blocks of data, and evaluating the differences in
> sequence numbers
> to detect if text or audio was lost in the audio/t140 case. All these
> proposed methods
> appeared to have logic weaknesses, so we prefer to stay with the more
> bit consuming but
> more reliable and simple method based on the t140block counter.
I don't think bit-rate consumption in the payload for real users is a 
major consideration. I can agree that alignment would have been nice, 
however I think that robustness is more important.

[snip]
> 13. Late and false detection of loss in the audio/t140 and text/t140
> format
> In the formats without redundancy, the current procedures will not
> reveal loss until next
> real character is transmitted. That may take minutes. A proposal is to
> introduce and send
> the same empty block once after the buffering timeout. Next time there
> is something real
> to send, it should be sent with the M-bit.
> Loss of the last real character may be detected soon, if the empty block
> is received.
> If the last, empty block is lost, but next block, sent with M-bit is
> received, a rule can
> be that a gap of two in sequence number when M-bit is received shall not
> be reported as
> loss. A gap of three or more shall be reported as loss. If the block
> with the M-bit is
> lost, real data is lost, and next reception will show no M-bit and a
> number gap of 2 or
> more that leads to indication of loss.
>
> This procedure need to be defined with MUST for both transmission of
> empty block and for
> transmission of M-bit and use of the logic for detection of loss,
> otherwise there will be
> false detections and missed detections if different applications
> implement different
> parts.
>
> One side effect will be packets with just empty blocks taking up
> bandwidth.
> I want to check the feelings for introducing this method.
As I understand it, this is the case when no RFC 2198 redundancy is 
used, and some other mechanism for reliability is used. When the last 
transmitted packet is lost, you are claiming that it might be minutes 
until this loss i detected. However, I think you have forgotten RTCP SR 
packets. If one uses RTCP, there should be two RTCP SR packets sent, 
which will both indicate that this RTP packet has been sent. Of course 
they can be both be lost. But there is need for 3 lost packets instead 
of only one, as you thought. Thus I don't know how sensitive problem 
this is.

A sender could also monitor the receiver reports from the client, if 
they never reports the last packet received, one could send out an empty 
block, to ensure that it is received.

If one does this, one can in most cases ensure that a receiver either 
gets the text block, or at least detect it as lost. And doing the smart 
thing at either end will reduce the risk of false indication to a level 
where it is not worth reporting. I would avoid any receiver heuristics 
for when a packet should be marked lost or not. Because they are likely 
to produce more errors then expected. Having a rule allowing a receiver 
to remove a loss marker after a while, does not seem to make much 
improvement.

Isn't it also that if these mistakes are rare enough, we can let the 
human repair mechanism take care of it.

Cheers

Magnus
--

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt