RE: [AVT] AD questions on draft-ietf-avt-ulp

["Mark Watson" <[e-mail]>]

Magnus,

Cullen said:
> Is a m(i) of 48 bits enough for things like mpeg?

And you replied: "I would claim that your statement provides to little
info to be evaluated. 48 bits are enough for most applications in the
kilo bit 
range, for applications in the megabit range it is probably not enough."

I don't agree with the first part of the second sentence - it depends
entirely on the level of errors you want to correct, the amount of
bandwidth and latency that you can afford and the packet size. 48 is
really very limiting in many applications, including those in the kilo
bit range. But I think it's understood that this draft has a limited
scope of applicability. Extending past 48 might require a change from
the bitmap approach, since otherwise the overhead of the bitmap itself
starts to become excessive.

Regards,

Mark 

-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Monday, May 15, 2006 5:29 PM
To: Cullen Jennings
Cc: IETF-AVT; Colin Perkins
Subject: Re: [AVT] AD questions on draft-ietf-avt-ulp

Hi Cullen,

I will provide my view on your comments. However I would appreciate if 
you in the future where a bit more specific about what your comments 
applies to.

Cullen Jennings wrote:
> I had several questions and concerns about this draft. I cc'd Jonathan

> as he was going to do an expert review. Likewise, Mark, as an review
of 
> this, do you  still have concerns that are not addressed that you
think 
> need to be fixed for this to go to RFC?
> 
> First of all, i raised a bunch of questions here - Do feel free to
push 
> back hard where I am confused, wrong etc. I have not been following
this 
> work, I am just reading it now, and have a somewhat limited amount of 
> time to read all the background and really come up to speed on the
whole 
> topic. You will need to help educate me and I would be pleased to find

> out the document is fine and I am confused.
> 
> Major Items ------------
> 
> Is this backwards compatible with a device that does 2733. If not I
have 
> concerns about obsoleting it?

It is not backwards compatible with RFC 2733. The reason why it is not 
is that RFC 2733 breaks RTP processing. So we really like to say: Hey, 
RFC 2733 is broken stop using it. Use this instead if RFC 2733 would 
have worked for you.

> 
> Can we have a way of signaling baseline and extended mode support? I 
> would not want to have all old 2733 devices be required to support 
> extended mode. Can we separate baseline and extended mode into two 
> specifications.

Sure, you can have it for the price of creating less interoperability. 
As we are not backwards compatible with RFC 2733, there is no deployed 
base to consider. I don't think the WG appreciate to do the work of 
splitting these specifications. This spec is something that should have 
complete years ago.


> 
> I am unclear how a receiver wold know what order to apply SRTP/FEC 
> processing. I am unconvinced there is a need for multiple ways of
doing 
> this. The security section needs discussion of problems with two time 
> pads when doing this. It also will need security review with respect
to 
> two time pads issues from some security person.

The order is defined by an SRTP parameter, see RFC 3711. Secondly I 
don't see how a payload can result in two time pad issues. Although we 
can send the same or similar data in multiple packets, but that do not 
create a two time pad issues. The two time pad issues with SRTP is if 
multiple payload are encrypted using the same key and IV. To my 
knowledge the presented usage of ULP does not create any such issues.

I agree that security review is good. I have expected that the SRTP 
people on the list has taken a look. However I guess that is a bit 
optimistic without explicit requests. So please solicit further review.

> 
> Is specifying the mask and m(i) and L(k) in every packet the right 
> design choice. This uses a lot of bandwidth and seems like information

> that would not need to be specified every time.

That can of course be discussed, but we was primarily doing a RFC 2733 
replacement.

> 
> The document needs a sane and rational applicability statement. There 
> are definitely deployment trade offs where this approach would not be 
> the best way to go. Need to explain how and when this should be used.

> Given we are forming a WG to deal with FEC, this document needs to
also 
> address when to use generic approaches vs these.

What part of the statement do you not fine sane? Please consider that 
this statement was written when UXP was developed and a competitor with 
ULP. If anything I think we should drop anything talking about other 
mechanism not yet defined. I don't think we can talk about comparing 
this with FECFRAME, because that solutions properties are not yet known.

So if anything it should be focused on what it is capable of.

> 
> I am unclear on what level of reconstruction is provided or what we
are 
> tying to do with the multiple levels. For example, take the example in

> figure 5. Here 8 payloads are sent and 7 payloads worth of parity bits

> are sent so we are sending nearly as much FEC data as original data
and 
> introducing significant decode latency. Yet if payload 0 and 1 are
lost, 
> it does not seem like they can be reconstructed. I hope I am wrong
here 
> - it seems like with this amount of bits allocated to FEC we should be

> apply to loose any 3 packets and still recover all the data. Please
help 
> me understand. Can both 0  and 1 be recovered?

I think you are correct, that loss of payload packet 0 an 1 result in a 
failure to recover 0 and 1 at level 0, 0,1,2, and 3 at level 1 and 0-7 
at level 2.

> 
> It is unclear to me how the receiver will know if it  has enough
buffer 
> to decode the FEC stream that will be sent to it. It needs to know
this 
> when it decided if it wants the FEC stream or not.

There is no information on this. The 48 bit mask put certain 
restrictions on the buffer size.

> 
> The basic operation section that tries to give the overview of how the

> scheme works is very confusing for people not already familiar with
the 
> scheme. Let me be very blunt - I gave it to three different developers

> all familiar with RTP and none of them could figure out how this works

> or what it does. Part of the issue is that the term level is used
before 
> it ever introduced.

Okay, if you mean section 3, then I guess it can be improved. Is the 
real description understandable so that one can basically delete this 
section?

> 
> 
> Minor Items ---------------
> 
> Is a m(i) of 48 bits enough for things like mpeg?

I would claim that your statement provides to little info to be 
evaluated. 48 bits are enough for most applications in the kilo bit 
range, for applications in the megabit range it is probably not enough.

> 
> How does this work to FEC something where the next packet may not
happen 
> for a very long time like DTMF or text.

That is an interesting thing. But if no packet is sent, you can change 
your FEC encoding and send a repair packet based on a timer. Please 
remember that ULP can support packet replication by stating it is the 
XOR of a single packet.

> 
> Given the packet overhead, would this be the recommended way to 
> protecting say 20 ms G.729 audio packets in an interactive voice 
> conversation.

In those cases I think RFC 2198 is a better way, even when using it to 
duplicate the complete frames.

> 
> Nice to point out some example audio codecs that benefit from ULP.
> 
> When doing FEC on an encrypted packet, the encryption is very likely
to 
> make ULP useless - should carefully consider and discuss.

This depends on the encryption algorithm, if block cipher is used, yes. 
For stream ciphers, no. But you are correct that this should be included

in the security consideration.

> 
> Would there ever be a case to have both integrity protection and ULP? 
> Seems weird.

Yes, only if partial protection is available will it make sense.

> 
> I think that is the media is encrypted, then the FEC MUST be encrypted

> too ( not should ) and similarly with integrity.

Yes, but then one needs to state the exception if one applies the FEC 
afterwards.

> 
> In section 11, the discussion of changing media encryption keys and
how 
> that relates to decoding the FEC packets, seems, ah, wrong. Perhaps it

> is right but more is needed on this.

I agree it is a bit unclear. There is some issues with caching of keys 
if one applies FEC to already encrypted packets, as the key will be 
needed after recovery. There is also the interaction between the two 
streams if encryption is applied to one source data RTP session and one 
with FEC data. If the key changes are used for access restriction then 
such changes may have strange results unless the keys in both session 
are changes at the same time.

> 
> Section 12, 2nd para. This tells implementers they MUST do something. 
> However, I have no idea what they need to implement here. We need to 
> give advice on what they implementers need to do - as it is, it does
not 
> seem implementable.

What, to have a knob on your FEC encoder to determine who much output 
you get. I think it is implementable, however not very simple.

> 
> The advice on using FEC and redundant encoding or separate stream is 
> somewhat unsettling. First it say SHOULD do it as separate stream and 
> provided no exception when you would not then goes on for a few
section 
> on telling you how to violate this SHOULD. Would be nice to have
advice 
> on when an implementation uses each one (or just define one way). I
will 
> note that from a bandwidth tracking for RSVP and flow set up for ICE 
> point of view, redundant encoding has advantages.
> 

Okay, agreed, it probably should explain in which cases breaking the 
should may be motivated.

> 
> 
> IANA registration - I don't think the change controller should be a WG

> as they get closed.

Actually this is by the IESG agreed sentence that has been used the last

few years on all of AVTs payload formats. The thing is that it reverts 
back to the IESG if the WG is closed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt