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

["Gunnar Hellstrom" <[e-mail]>]

Satish,
We crossposted.

-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: Mundra, Satish [mailto:[e-mail]]
> Sent: Tuesday, May 11, 2004 12:27 AM
> To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF
> Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-03/04
>
>
> 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:[e-mail]]
> > 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
> > [phone]
> > Mob: [phone]
> > www.omnitor.se
> > [e-mail]
> > --------------------------------------------
> >
> >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:[e-mail]]
> > > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt