[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
>
> > > 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