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

["Mundra, Satish" <smundra at telogy.com>]

Gunnar/Paul,

See one more comment inline...
I think that comments/question can be revisited after basic issue with 
the use of Mbit and t140block counter is concluded. Many other questions may
become
irrelevant then.

Regards,

Satish Mundra


> -----Original Message-----
> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] 
> Sent: Friday, May 07, 2004 1:19 AM
> To: Paul E. Jones; Mundra, Satish; avt IETF
> Subject: RE: [avt] Comments/questions on 
> draft-ietf-avt-rfc2793bis-03/04
> 
> 
> 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
> Gunnar.Hellstrom@Omnitor.se
> --------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > 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'll respond to some questions, but leave most to Gunnar:
> >
> > > > > 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.
> >
> > 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.
> 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.
> 
> >
> > > > > 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 ?
> >
> > 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.
> >
> 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.
> 
> > > 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.
> But text/t140 has 1000 Hz clock just with the reason that it 
> shall allow 16 seconds span for the redundancy.
> > >
> >
> > 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.
> >
> > > 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 ?
> 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.
> 
> >
> > 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.
> >
> > > 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.
> >
> > 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?
> 
> 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?
> 
> 


Here's one possibility:

1. The section "5.4" (version-04) defines the "Silent Periods" and
"zero-length" blocks.
 
2. Allow use of "zero-length" t140blocks during "Silent Periods" for both
text/t140 and audio/t140 (i.e. with or without redundancy use). 

3. Only one "zero-length" t140block MUST be transmitted every "Silence
Period".

4. Use M-bit to indicate start of every text-spurt.

[ Note that for audio/t140 this means that switch to voice payload can only
occur after a terminating zero-length block indicating silence period has
been transmitted. There's still 
an issue with detecting loss accurately under some specific bursty loss
scenarios and may need some solution if it's important.
Regarding M-bit usage: I think as far as audio/t140 is concerned, the use is
as specified in profile. For text media at present there is no profile
specifying the M-bit behavior. Behavior analogous to voice seems suitable
for text too and can be specified by 2793bis.]

If zero-length block is lost then the receiver will have to wait for next
packets arrival 
to determine/indicate if there was any actual data-loss, this behavior is
same as before.
The above scheme makes t140block counter redundant as the RTP seq# and
T140block counter would always be in sync during a text-spurt.
The marker bit's presence/absence/loss would enable one to distinguish
between loss of one or more normal T140block or zero-length block (with or
without RED use) and prevent false loss detection. This will allow use of
same payload format for both audio and text t140 and
I think same rules for redundancy use simplifying the implementation.

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

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