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

["Paul E. Jones" <paulej at packetizer.com>]

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.

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

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

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 ?

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?

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


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