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

From: Colin Perkins <[email-masked]>
Date: Fri, 14 May 2004 09:49:48 +0100

On Friday 30 April 2004 19:51, Colin Perkins wrote:
> This is to announce a working group last call on the "text/red" MIME
> type registration <draft-ietf-avt-text-red-04.txt>, and the RTP Payload
> Format for Text Conversation <draft-ietf-avt-rfc2793bis-04.txt>. Both
> drafts are under consideration for proposed standard status.
>
> Please send any final comments on these drafts to the mailing list
> before Friday 14th May 2004. Note that we will not advance either draft
> until we receive a valid review of the work by someone other than the
> authors.

The working group last call for these drafts ends today. 

There has been considerable discussion of the 2793bis draft on the mailing 
list, thanks to the review by Satish Mundra, and it appears that there are 
open issues to resolve. Accordingly, we will not advance the 2793bis draft 
until a revision is available that addresses these concerns.

The text/red draft has not yet received a public last call review, even 
through there are 1077 people on the list who received the request for 
input.  Accordingly, it will continue in working group last call until 
such a review is received. 

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 16 May 2004 23:17:52 +0200

Colin and all,
Thanks for fruitful review and discussion.

We will make a new revision available.
This is where the current revision is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-04.txt

I have the following notes about things to change, or things discussed:

1. Section 3.6. Use of M-bit.
Use of M-bit shall be recommended to mark beginning of new text after a period of silence,
just as in the AVP profile.
I see that some applications may find this useful and we do not want to hinder that. The
SHOULD for transmission will be included without any recommendation about what the
receiver shall do.
But see discussion under 13 for possible sharpening of this statement.

2. Section 4, insert word "protection" before "methods" in next-to-last line makes it more
clear what it is about.

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.

4. The first two paragraphs of 4.2 should be valid for audio/t140 as well and should
therefore be moved to sec. 4.1. The corresponding part in section 4.3 can be deleted.

5. In sec 4.3. Insert a clarification that the length indicator of the redundant block
includes the t140 counter.

6. Section 5.4. Make it clear that when using red payload, it should be used all through
the session. ( with change 3 above, we always have redundant blocks, except in the first
packet.

7 Last example in sec 7.1. The R2 and R1 mark should change places. Newer data is placed
after older.

8 Last example in sec 7.2. The F-bit of the last redundancy header s.b. 0

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.

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.

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.

12. False detection of loss in the text/red/t140 format.
A small risk for false detection of loss has been pointed out in the text/red/t140 format.
If all transmissions of an empty block are lost, the receiver may deduct that text is lost
and indicate that to the upper layers. But no text was lost, just an empty block.

We want to maintain interoperability with RFC2793, and that reduces the opportunity to do
anything about this risk. The rule in item 3 above helps to some degree.

There are other "invisible" characters in T.140, e.g. the "bell" for audible, visible or
tactile alerting during call. Loss of it will be also marked by a missing text marker even
if nothing is missing in the visual presentation. Therefore the users will understand the
missing text indicator that there MAY have been a loss of visible characters. Therefore it
is better to give some false indications than to drop text without marking it.

Thus the currently defined procedures are suitable and no change is needed.

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.

14. The "text spurt" concept.
In the discussions, the word "text spurt" has been used often. I hope that it has not
influenced anyone to believe that text and voice must come in "spurts" and take turns. It
was an unfortune functional limitation in most old text telephone systems in PSTN, but it
is definitely not the way users want to use text and voice in a call. An opportunity to
use both media in parallell is what the users want, and it can easily be achieved in IP
transmission.
Conclusion: Avoid influencing the transmission methods by organising transmission in
spurts. Let it be a matter at the terminals or gateways.

Regards
Gunnar

-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
Perkins
Sent: Friday, May 14, 2004 10:50 AM
To: [email-masked]
Subject: Re: [AVT] WG last call: text/red and RFC2793bis

--
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 May 2004 10:09:11 +0200

Hi Gunnar,

I have some comments:

Gunnar Hellstrom wrote:

[snip]

> simplifies logic for detection of loss, and avoiding false detection of

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]
> the example, but the figure only shows one redundant header. Insert one

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.

> 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.

> 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]
> 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: [email-masked]