[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] WG last call: text/red and RFC2793bis
Magnus,
Thanks, I have now edited a draft new rfc2793bis. Before publishing it, I want to comment
on the comments received.
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom at Omnitor.se
--------------------------------------------
-----Original Message-----
From: avt-admin at ietf.org [mailto:avt-admin at ietf.org]On Behalf Of Magnus
Westerlund
Sent: Monday, May 17, 2004 10:09 AM
To: Gunnar Hellstrom
Cc: avt at ietf.org
Subject: Re: [AVT] WG last call: text/red and RFC2793bis
Hi Gunnar,
I have some comments:
Gunnar Hellstrom wrote:
[snip]
>
> 3. Section 4.2. transmission of old redundant data.
> Change rule about redundant data older than 16383 ticks. Include them,
> but set the
> timestamp offset to hex 3FFF. We never used the timestamp of text for
> anything. The
> receiver may decide if it is still appropriate to present the text. This
> new strategy
> simplifies logic for detection of loss, and avoiding false detection of
> loss.
>
It might look fine, doing what you proposed. However I see a few
problems, that you will need to verify that you have thought of:
A. If multiple text blocks fall outside of the 16383 ticks, then you
will recover multiple text blocks with equal timestamp. That violates
one of your must.
<GH> the MUST was only for the original timestamp inserted in the RTP header. Here we are
talking about the offset in the redundant data.
B. How will old implementations react to this change? According to the
old draft, a implementation may very well use the timestamp to check if
the text block is the same as a previous one. Thus I think this change
has interoperability issues.
<GH>It is explicitly said before that the timestamp is not sufficient for checking loss or
order, and that the sequence number shall be used for that purpose. Furthermore, only
empty T140blocks have a risk to get the old 16383 time offset, so nothing will be seen if
an application happened to regard the empty block as new empty data.
[snip]
>
> 9 Last example in sec 7.2. The text says that there are two levels of
> redundant info in
> the example, but the figure only shows one redundant header. Insert one
> more.
This is in fact not an error, according to your own rules, if one reads
the text completely:
"As a follow-on to the previous example, the example below shows
the next RTP packet in the sequence which does contain a new real
T140block when using the audio/t140 payload format. This
example has 2 levels of redundancy and one primary data block.
Since the previous primary block was empty, no redundant data
is included for that block. This is because when using the
audio/t140 payload format, any previously transmitted "empty"
T140blocks are NOT included as redundant data in subsequent
packets."
<GH> Thanks, you are right.
You get the explanation in the last sentence. If it is desired to think
of non sent block as impacting redundancy or not is another question.
You will have to consider if it is more logical to repeat the same
packet more than once, letting the receiver use the T140block counter to
detect this, or in fact move on and include the empty blocks in the shift.
<GH> In earlier versions, I have got the comment that I had to specify that just sending a
copy of a packet is not a good way to introduce redundancy because it corrupts the RTCP
reports.
I deleted that sentence a couple of versions ago, but did not expect that we should take
as a regular method to just repeat packages.
However, if we start using info from RTCP, I think that pure retransmission of packets is
the correct method.
>
> 10 Section 3.2. T140block counter initialized to zero is a security
> weakness.
> We got a comment that it opens to security attacks to specify that the
> t140block counter
> shall begin with the value zero. This value was selected in order to be
> able to detect
> loss of the first block. In T.140, there is a requirement that the
> session shall start
> with a Unicode synchronization character. Even if there is no
> instruction today in T.140
> to indicate that the synch character is missing, applications can do so.
>
> However, the counter is a field in the payload, and it is common to have
> fixed patterns,
> like start-of-picture, start-of-block etc. in the payloads.
>
> We can change the text to require that the t140block counter shall start
> with a random
> value, and hint that upper layers should indicate loss of the synch
> character.
>
> I would like a second opinion on the importance of avoiding initial zero
> value on
> t140block counter before we do this change.
This depends on the cipher used when performing the encryption. For
example in SRTP the ciphers defined for usage, all have the property of
being resistant to known plain text attacks. I totally agree with the
sentence in SRTP RFC 3711, section 9.3:
As some RTP packet could contain highly predictable data, e.g., SID,
it is important to use a cipher designed to resist known plain text
attacks (which is the current practice).
An older cipher may not have this property. Which is likely based on the
random tag for RTCP, and other things in RTP. However I think this
property is necessary for any cipher being used with RTP. Because it is
predictable to a large extent. Therefore any cipher not having this
property should be replaced. And I don't see that RFC 2793bis makes this
worse. I hope that any security expert will correct me if what I write
is wrong.
Therefore I think you will be safe to define it as starting a 0. However
in certain applications, for example multiparty sessions, the start at 0
will give very little information, e.g. for late joiners. Basically it
could only be used to count how many text blocks a certain user has
sent. Thus I don't see any real gain of starting at 0.
<GH>Late joiners in a conference will understand that they just jump in anywhere in the
stream. In the person to person call application it creates comnfusion if the first
characters are missing just as it does if the first words of speech are dropped.
So, I suggest that we keep the start at 0.
>
> 11. Find another solution for loss detection in audio/t140 than
> introducing the t140block
> counter.
> We had discussions on ways to avoid using the t140block counter for
> audio/t140 in order to
> save bits and make the two formats more equal. Methods were proposed
> based on the M-bit
> and detection of empty blocks of data, and evaluating the differences in
> sequence numbers
> to detect if text or audio was lost in the audio/t140 case. All these
> proposed methods
> appeared to have logic weaknesses, so we prefer to stay with the more
> bit consuming but
> more reliable and simple method based on the t140block counter.
>
I don't think bit-rate consumption in the payload for real users is a
major consideration. I can agree that alignment would have been nice,
however I think that robustness is more important.
[snip]
<GH> Yes, keep the formats.
>
> 13. Late and false detection of loss in the audio/t140 and text/t140
> format
> In the formats without redundancy, the current procedures will not
> reveal loss until next
> real character is transmitted. That may take minutes. A proposal is to
> introduce and send
> the same empty block once after the buffering timeout. Next time there
> is something real
> to send, it should be sent with the M-bit.
> Loss of the last real character may be detected soon, if the empty block
> is received.
> If the last, empty block is lost, but next block, sent with M-bit is
> received, a rule can
> be that a gap of two in sequence number when M-bit is received shall not
> be reported as
> loss. A gap of three or more shall be reported as loss. If the block
> with the M-bit is
> lost, real data is lost, and next reception will show no M-bit and a
> number gap of 2 or
> more that leads to indication of loss.
>
> This procedure need to be defined with MUST for both transmission of
> empty block and for
> transmission of M-bit and use of the logic for detection of loss,
> otherwise there will be
> false detections and missed detections if different applications
> implement different
> parts.
>
> One side effect will be packets with just empty blocks taking up
> bandwidth.
> I want to check the feelings for introducing this method.
>
As I understand it, this is the case when no RFC 2198 redundancy is
used, and some other mechanism for reliability is used. When the last
transmitted packet is lost, you are claiming that it might be minutes
until this loss i detected. However, I think you have forgotten RTCP SR
packets. If one uses RTCP, there should be two RTCP SR packets sent,
which will both indicate that this RTP packet has been sent. Of course
they can be both be lost. But there is need for 3 lost packets instead
of only one, as you thought. Thus I don't know how sensitive problem
this is.
A sender could also monitor the receiver reports from the client, if
they never reports the last packet received, one could send out an empty
block, to ensure that it is received.
If one does this, one can in most cases ensure that a receiver either
gets the text block, or at least detect it as lost. And doing the smart
thing at either end will reduce the risk of false indication to a level
where it is not worth reporting. I would avoid any receiver heuristics
for when a packet should be marked lost or not. Because they are likely
to produce more errors then expected. Having a rule allowing a receiver
to remove a loss marker after a while, does not seem to make much
improvement.
<GH> Thanks for hinting on RTCP. I think it can be very useful if you want to improve
reporting or even recovery. I will introduce a hint for that.
More about M-bit etc. in another mail.
Isn't it also that if these mistakes are rare enough, we can let the
human repair mechanism take care of it.
<GH> Yes, just as with voice calls. But it is better to mark loss that has not happened
than to miss to mark a loss.
Cheers
Magnus
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt