Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-03/04

From: "Mundra, Satish" <[email-masked]>
Date: Thu, 6 May 2004 11:28:22 -0400

Gunnar,

See further comments inline...

X---snip...
> > 1. In section 3.2 : "The T140block counter MUST be 
> initialized to zero 
> > the first time
> > that a packet containing...."
> >
> > Initializing this counter to zero will make it weaker against 
> > encryption attacks when RTP payload is encrypted.
> This is still in 3.2
> 
> There are also other fields that are easy to derive. This is 
> no worse. We want to check missing text from first character 
> if it arrives. This was one feasible way to achieve that goal.
> 

I agree that there may be other fields which are easy to derive, but what if

implementations or standards are revised in future. Those may not apply to
payload where
this sequence # is present. More randomization is always preferable. 

In any case, the text/t140 will have a random sequence number on very first
packet so the 
initialization to zero for audio/t140 alone, has not resolved the same issue
with text/t140.
 
The M-bit behavior as per the AVT profile [ see 2 below] will allow the
detection of the 
loss of characters from first packet. If the first packet that is received
does not have 
M-bit set then one can conclude that one or more characters were lost. 

> >
> > 2. Section 3.7 states "M-bit: The M-bit has no defined meaning for 
> > t140 text streams and MUST be set to 0."
> >
> > For audio/t140 this should be set on the first packet of the 
> > text-spurt (start of t140 payload after a period of silence ) as 
> > recommended in RTP/AVT.  Why audio/t140 should be treated any 
> > different from other audio encoding methods ?
> This is now in sec 3.6
> 
> There is no reliability in the M-bit. Therefore it does not 
> add any value to use it.
> 

I agree that there is no reliability and moreover M-bit is not preserved by
2198 
redundancy header but that just means that receivers can not depend on
receiving it such packet all the time. See comments above[1], when present
will allow detection of loss at 
the beginning. I would think that instead of not defining any meaning, a
behavior as per 
the AVT profile is preferable. I don't see any advantage in not defining
some useful 
behavior.

> >
> > 3. Section 3.9 states:  "- Each redundant data block MUST 
> contain the 
> > same data as a T140block previously transmitted as primary 
> data, and 
> > be identified with a timestamp offset
> > equating to the original timestamp for that T140block."
> >
> > This conflicts with Section 3.8  sates "Redundant data older than 
> > 16383 divided by the clock frequency MUST NOT be transmitted."
> This is now in sec 4.2 and 4.1
> 
> It means "what you put in a redundant data block MUST have 
> been transmitted before as primary and the timestamp of the 
> primary MUST be possible to calculate from the offset in the 
> redundant one." I think it is clear and suggest no change.
> 

The primary that was sent can be lost, so a receiver can not rely of
receiving primary 
and needs to be prepared to deduce the sequence numbers from timestamp
offsets alone in
particular packet, so why a MUST ? 

If the redundant data is older that (2.048 Secs fro 8Khz clock OR 20.48 sec
for 1Khz), one
can not send that data as redundancy payload as the timestamp offset will be
more that 
13bits as noted in ( sec 4.2 in -04). In that case, one can not satisfy
"MUST contain the
same data previously transmitted as primary" which is important for making
accurate loss
detection for text/t140.

Any zero-length t140 blocks transmitted as  primary for text/t140 MUST be
sent again as
redundant block[4a below], what will one do if after transmitting a
zero-length block, the
next data is not available for more than 21 seconds or so. Should one keep
sending 
zero-length blocks so as to ensure that sequence number deduction would be
feasible ?

> >
> > 4a. Section 4.5 states "When using the text/t140 payload 
> format, any 
> > zero-length T140blocks that are sent as primary data MUST 
> be included 
> > as redundant T140blocks on subsequent packets just as normal text 
> > T140blocks would be so that sequence
> > number inference for the redundant T140blocks will be correct,
> > as explained
> > in section 3.9.
> >
> > It not clear if the MUST is only applicable if one continues to 
> > transmit payload RED. I would assume that one could switch to t140 
> > payload for the first packet after the "silence period". A 
> > clarification text regarding switching to t140
> > payload, if permitted, would be
> > helpful.
> This is now in 4.2.
> 
> If a T140 block has been sent the number of times intended ( 
> primary and a configured number of redundant ), it shall not 
> be sent again. When there is no new text input, redundant 
> transmissions will take place at the buffering time interval 
> ( 300 ms recommended ) until all t140blocks have been 
> transmitted as redundant data the planned number of times. 
> Not until then transmission stops.
> 
> After a pause, there is no old text to transmit. So both if 
> you send next packet as text/t.140 or as text/red, it would 
> only contain the new data. I suggest that you stay with the 
> text/red format. All procedures with redundancy will work in 
> both cases.
> 
> I agree that a clarification that both are permitted could be helpful.
> 
> <<<<change
> Add the
> 
OK.

In either case, there is a issue when the packet with "zero-length" block as
primary is
lost for text/t140. If you don't send it as redundant data or switch to
text/t140.
A receiver will see a sequence # gap and will indicate loss of text-data
when there was
none. 

X---snip

> >
> > 5. Reading of Section 3.8/3.9/4.5 suggests that "RFC2198 
> -RTP Payload 
> > for Redundant Audio Data" which is suitable for audio data requires 
> > additional rules/restrictions for text
> > data where sequence numbers instead of relative timestamps are
> > of interest.
> > IMO, a new RTP payload format for redundant text data 
> should be specified
> > where the redundancy header includes the "RTP sequence 
> number offset"
> > instead of the timestamp offset. This would simplify the redundancy
> > mechanism for text where the goal is to infer the sequence number
> > correctly and not the timestamp.
> 
> This is now in sec 4.3.
> 
> Agreed that it could be done, but we wanted to keep things 
> simple use RFC 2198 as it was. If we created another 
> redundancy mechanism, it would just be another barrier for 
> people to cross in order to implement RFC 2793bis.
> 
  Having different payload format for auidio/t140 and text/t140 and
different behavior for
zero-length-block behavior and condition in Sec. 4.2/4.3( of -04 version),
IMHO, is
redefining the 2198 to make it suitable for non-audio data to enable one to
deduce to seq#
from timestamp-offsets. I guess it's debatable as to which one is a bigger
barrier to cross.

X---snip

> >
> > 7. The benefits of introducing T140block counter are not 
> clear.  This
> > counter is not a character counter which probably could 
> help identifying
> > exact number of characters lost.
> 
> Having a character counter would not give much more information.
> Transmissions in T.140 may consist of displayable text, it 
> may be edits (
> e.g. "erase last character" ), it may be combinable characters that
> influence the adjacent character, it may be a beep, and it 
> may be control
> codes for change of character rendition. So, an exact number 
> of indicators
> would not mean anything else than the current situation with 
> one marker
> character per missing packet.
> 
> 

OK. 

> > One can detect loss/duplicate packets using the RTP sequence
> > numbers/timestamps. During a text-spurt transmission both 
> RTP sequence
> > numbers and T140block counters would be in sync.
> > If one could identify the first packet of text-spurt with 
> marker bit then
> > receiver would not be confused regarding loss, although the 
> detection of
> > loss of the last packet in a spurt could still be difficult 
> depending on
> > what follows. You have noted that event with T140block counter
> > the loss of
> > the last packet of a sequence of packets cannot be detected
> > until the next
> > text packet is transmitted. Why, it's not desirable to specify
> > appropriate
> > M-bit behavior instead of an additional 2byte counter in 
> every packet ?
> 
> The M-bit can not be relied upon, because the M-bit is 
> transmitted once
> only. If that packet is lost, you lost the indicator.
> 

Yes, but the fact that one received a packet with M-bit not set when one was
expecting one, at the beginning of text-spurt, is an indication of loss.
There by serving the purpose that "t140 block counter" is serving, namely
indicate "loss of one or more characters". I still do not see benefits of
introducing this counter when it appears that the same can be accomplished
by using M-bit.

Regards,

Satish Mundra

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 May 2004 17:10:18 -0400

Satish,

> initialization to zero for audio/t140 alone, has not resolved the same
issue

You have a good point about not being able to detect the loss of an initial
character in text/t140.  I believe that is right.

I'm less concerned with being able to use information about part of the
contents of a particular packet.  It might make it vulnerable to attack, but
it also shows a weakness in the encryption that is used.  With many codecs,
some of the bits within the payload have a value that is known or can be
guessed.  I suppose the T140block counter offers the largest number of such
bits.

I don't have an incredibly strong feeling one way or the other.  But, I
would like suggestions on how to determine the loss of the initial character
if we change the value (I know you like the M bit).  Perhaps it is simply
not that important to detect loss of the initial character.

> particular packet, so why a MUST ?

Which MUST are you concerned about?  The requirement that the redundancy
packet MUST carry the previous primary data?  It is not possible to
determine the sequence number based only on the timestamps for text, as text
is not constantly flowing.  But, I may have misunderstood your point.

> same data previously transmitted as primary" which is important for making

Agreed.  The text recommends transmitting at 300ms.  With two levels of
redundancy, we're OK.  If we have more redundancy, the interval must be
faster (but more redundancy is really not necessary).  Also, audio/t140
re-transmission is likely to be much faster than text/t140, especially when
voice is detected and also needs to be transmitted.

> zero-length blocks so as to ensure that sequence number deduction would be

We must make sure there are no gaps, so even after 21 seconds, the next
text/t140 packet must contain any previous empty "primary" data T140blocks.

> A receiver will see a sequence # gap and will indicate loss of text-data

You're saying that if we send this packet:
   { R1(text), R2(empty), P1(empty) }

And then there is nothing to transmit for a while and the next packet looks
like this:
   { P1'(non-empty }

Then the receiver will wonder what happend to the sequence number associated
with P1(empty)?  I think you might be correct.  This might cause incorrect
interpretations of lost characters for text/t140.  Audio/t140 does not have
the same problem, as it has the T140block counter inside the payload.
Gunnar?

> introducing this counter when it appears that the same can be accomplished

The M-bit cannot stand in for the T140block counter.  Even with significant
congestion and the loss of 10 packets in a row, the T140block counter can
indicate loss, whereas the M-bit would have been lost 7 packets earlier.

I honestly think the use of the M-bit is questionable for text.  I can see
some utility in voice packets *if* it were reliably delivered.  Given that
it can be lost, the receiver has to be prepared to function properly without
it... so why bother?  Another argument we could make is that since there is
no silence suppression, we should set it to zero (RFC 3551).  Perhaps that's
a stretch, but I largely think it's about the same... I just cannot see any
utility of the market bit in the text applications.

Paul

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 7 May 2004 07:19:00 +0200

Satish,
Further answers inline,

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: Paul E. Jones [mailto:[email-masked]]
> Sent: Thursday, May 06, 2004 11:10 PM
> To: Mundra, Satish; 'Gunnar Hellstrom'; avt IETF
> Subject: Re: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-03/04
>
>
> Satish,
>
> > I agree that there may be other fields which are easy to
> derive, but what
> if
> >
T.140 requests that the first character sent in a session is a UTF-8
synchronisation character.
"7.1	Code signature and synchronization
The ZERO WIDTH NO-BREAK SPACE character (FEFF) shall be inserted in the
beginning of the session. "
So, a receiving T.140 could check the first character. If it is not the
sync character, one or more characters can be assumed to be lost, and it is
suitable to mark the loss.

> is not constantly flowing.  But, I may have misunderstood your point.
The MUST makes it still possible to deduct the timestamp of the text. Even
if it can not be used for detection of loss, some designer may want to use
the timestamp e.g. for planning of playout, conversion to the timed-text
format or so.

> > can not send that data as redundancy payload as the timestamp
> offset will
> be
> > more that
But text/t140 has 1000 Hz clock just with the reason that it shall allow 16
seconds span for the redundancy.
> > zero-length blocks so as to ensure that sequence number
No, you "pump out" the last text as redundant text at 300 ms intervals. If
you have the recommended two levels of redundancy, the last characters
before a pause will sent as primary, then as secondary after 300 ms and
then as tertiary after 600 ms. Then it is silent and nothing is in
transmission buffers. When new text is coming from the user to be sent, it
will be sent as primary text and no secondary exists to be transmitted.

This mechanism is described in the section about silence.

> > In either case, there is a issue when the packet with
> "zero-length" block
> as
> > primary is

Yes, there is a spotted problem, but the description above is not correct.

1 send { R2(text x), R1(text y), P1(text z) }    and receive it
no more input causes after 300 ms
2 send { R2(text y), R1(text z), P1(empty) }     assume lost
after 300 ms
3 send { R2(text z), R1(empty), P1(empty) }     assume lost

after 21 seconds the user types text q.
4 send { P1(text q) } with text/red payload type    receive it   -
Because the old R1 and R1 are so old that thy should not be sent.

This reveals a sequence number loss 2 and 3, and no information available
to repair the loss with. So, according to current logic in rfc2793bis, the
loss should be marked. And it was only empty fields that we lost, so it
will be a false mark.

It does not help to send the new packet with text/t140, the gap will be
noticed and marked anyway.

It helps a little if we allow data older than 16383 ticks to be tranmitted.
Then, the
4b send { R2(empty), R1(empty), P1(text q) } received would reveal that
nothing was lost,

But losing also 4b would create a false loss detected when transmission 5
is received.

This is unfortunate but not unacceptable. We have not promised total
reliability on the indicator for missing data.

Do you have a proposal for how to reduce the risk of misdetection of loss?

> > Yes, but the fact that one received a packet with M-bit not
> set when one
> was
Gunnar

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 11 May 2004 00:29:07 +0200

Satish,
I am eager to come to conclusions on your questions regarding
draft-ietf-avt-rfc2793bis-04.

Our (Paul´s and mine ) understanding regarding the questions are now:

1. Security risk to have the 16-bit T140block counter to always start at 0
in a session.
I mentioned that loss in the beginning could be detected by the text stream
not starting with the Unicode synchronization character, because the
requirement to start with that code is clearly stated in T.140.
So, that could be used and the counter could then start at a random value.
However, also this session start code can be seen as a security risk with
the same reason as the 0 counter would be one. Are not all media full of
predictable bit patterns, like picture start headers, audio session
parameters etc?

We would like to hear more voices if it is important to start the counter
at a random value, and instead rely on detection of initial loss by a
missing Unicode Synchronization character.

2. M-bit for indication of start of text.
You hint that we should specify that the M-bit SHALL be used as indicated
in the AVT profile for indicating start of text initially in the stream and
also after a gap. This could be used both to detect loss and in order to
detect when suspected loss is only loss of empty text blocks.

Each M-bit is only sent once, so it does not get improved reliability by
redundancy. We have a mechanism with marking missing text with a Unicode
replacement character, specified in T.140. If in doubt, it is better to
mark too much than too little, because there will be non-printable
characters that will be marked by this character when lost. Therefore the
users might know that there can be markers for missing text without any
visible text missing.

So, for audio/t140, we can select between three methods for indicating the
start of stream:
 a. counter =0
 b. M-bit
 c. Unicode start of stream character

For text/t140, we can only select between two methods:
 a. M-bit
 b. Unicode start of stream character

A missing M-bit does not give full information if a real text element is
missing. The text might be received in redundant code.  But it can be used
as a likely indication.

The other methods are at least as reliable as the redundant transmission
method used.

For text during a session, we have the following problem: What is a gap?
When shall the M-bit be set to 1? What is a text-spurt?

For text/t140, it is hard to find a good definitition for when a text-spurt
starts. There is no declaration of the time between the packets, just the
buffering time that normally may be 300 ms, but may vary. For the
text/red/t140 case, there could be a reason to use the M-bit, when only the
primary data contains valid text. The other blocks should be empty or
non-existing. That is the case after a pause.
Detection of an M-bit can make sure that the risk is kept low for falsely
marking loss of data during the pause. Without the use of the M-bit,
falsely marking lost text will occur slightly more often.

For the plain text/t140 format, I do not see any need for marking the first
packet after a longer pause.

For red/audio/t140 I see no need for the M-bit. The counter give a better
reliability.

The current RFC2793 does not specify the use of the M-bit. RFC2793bis
should be compatible with RFC2793 for text/t140 and text/red/t140. Using
the M-bit for RFC2793 bis would be a step off from that direction.

Anyway, it does little harm, so if there are voices for it, we could say
that the transmitter MUST use the M-bit to indicate start of stream, and
start after a pause. The receiver MAY use it for detection of loss.

Please advice

Regards

Gunnar
---------------------------------------------------------------------------
-------

Satish,
Further answers inline,

Gunnar

Gunnar