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

From: "Mundra, Satish" <[email-masked]>
Date: Tue, 11 May 2004 13:18:35 -0400

Gunnar/Paul,

Thanks for summarizing the questions. The previous comments got
cross-posted, I have used 
your latest posting for further debate on the questions/comments. 
See comments inline...

Regards,

Satish Mundra

> -----Original Message-----
> From: Gunnar Hellstrom [mailto:[email-masked]] 
> Sent: Monday, May 10, 2004 6:29 PM
> To: Paul E. Jones; Mundra, Satish; avt IETF
> Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04
> 
> 
> 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.
> 

See comments on the "t140block counter" below.
 
> 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.
> 

Yes.

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

Let me understand this again, the requirement for the payload format is to
NOT fail in detecting LOSS when occurs, misleading loss indicators are
unavoidable and seem to be acceptable. [see further comments on the block
counter below]

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

See comments on counter below.

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

Borrowing from section 5.4 of draft(04), gap would be "no new T.140 data to
transmit after the transmit buffering interval described in section 5.1 has
passed".  This defines the text-spurt which is analogous to talkspurt.

The M-bit behavior is from (RFC3551): "For applications which send either no
packets or occasional comfort-noise packets during silence, the first packet
of a talkspurt, that is, the first packet after a silence period during
which packets have not been transmitted contiguously, SHOULD be
distinguished by setting the marker bit in the RTP data header to one."

> For text/t140, it is hard to find a good delimitation 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.
> 

The text-spurt starts with the packet that you transmit after a zero-length
block is transmitted, that happens whenever the T.140 buffering interval
expires and no new data 
is available for transmission.

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

It helps in situations when one can not include a zero-length block as
redundant data 
because it's too old. 

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

During a interval where text is transmitted contiguously, the block-counter
and the RTP sequence numbers are in sync. So I guess the counter is only
useful at the boundaries when
switchover between voice/text payload is occurring.  Under certain loss
scenarios or when both marker and zero-length blocks are lost one could have
misleading text loss-indicator which in any case are unavoidable. In either
case you would detect loss as required.

As I mentioned earlier, I am unconvinced about the usefulness of the block
counter. During contiguous text transmission the counter and RTP sequence
numbers are in sync. Even if marker is lost, one could sync to the first
sequence number that can be deriver or is present in the header. IMO,
different redundancy rules for text/t140 and audio/t140 can be unified and
implementation simplified. 

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

X--------snip

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 12 May 2004 00:32:04 +0200

Satish,
I get the impression that your main goal with the discussion is to try to
find a format for audio/red/t140 that could allow us to drop the t140block
counter from the format.

Is the reason saving bits?

We have had it there since August, with no major concerns, so it seems
acceptable to most reviewers.

You also want to use the M-bit as in RFC3551.
> distinguished by setting the marker bit in the RTP data header to one."
That can be OK. But then you must not do anything drastic, such as adding a
missing text marker just because the packet with the M-bit seems to be
missing. With 10% packet loss, 10% of the M-bits will be missing, but only
0.1% of text, if we are using primary and two redundant transmissions.

Would it be OK to you to take in the text about the M-bit from RFC3551?

Gunnar

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Mundra,
> Satish
> Sent: Tuesday, May 11, 2004 7:19 PM
> To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF