Subject: RE: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt

From: "Gamze Seckin" <[email-masked]>
Date: Wed, 5 Nov 2003 15:29:14 -0800

Hi Magnus,

about your comment
"7. Section 2, You talk about AVP, but this extension is not dependent on 
any special profile and seems to be compatible with any of the four 
available or under development profiles that exist."

Do you also mean AVPF? Since I am confused about the relationship between AVPF and RFC3611.

thx
g
-----Original Message-----
From: Gamze Seckin 
Sent: Friday, October 31, 2003 11:08 AM
To: Magnus Westerlund; Alan Tseng
Cc: IETF AVT WG
Subject: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt

Hi Magnus, 
thanks for the comments.
See my response inline.

best regards
gamze
-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, October 29, 2003 8:17 AM
To: Alan Tseng; Gamze Seckin
Cc: IETF AVT WG
Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt

Hi,

Here is my comments on your draft:

1. First I think the draft isn't very clear on why any metrics are 
needed. In the 3GPP document it only states: "The objective of the 
streaming service quality metrics is to offer to the service providers 
means to evaluate the end user experience.". This doesn't make it very 
clear what the real needs are. I think further developing of this is 
needed.

[g]you are right, the draft does not talk about that clearly. We should add that.

2. Regarding the corruption statistics. For media that uses codec that 
have prediction any error normally remains for a rather long time. 
However it is very difficult to determine when the effects has been 
removed. Therefore this measurement is hard to derive on the receiver 
side. Combined with the definition it only provides a good, possibly bad 
indication. Also looking at the reasons for corruption, the only real 
reason is lost or late packets. A good feeling for the quality can be 
determined by the server simply by employing packet loss vector 
reporting and knowing when the buffer is empty.

[g]packet loss is definitely a way of estimating corruption, but this gives an algorithm in the decoder (or pre-decoder)a chance to provide better statistics.

3. The rebuffering measurements makes more sense. However there are at 
least one client that does not really perform rebuffering, namely 
quicktime. Instead is assumes that if the transmitted bit-rate is 
acceptable any short term effects will go away and the client will later 
  have a buffer fullness given by the initial buffering delay. The 
interesting thing about this measurement is that in 3GPP they already 
have a way of letting the server measure when rebuffering takes place, 
namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary 
versions available).

[g] yes, and I believe those statistics are useful, however they are tight with rate adaptation (only turned on when rate-adaptation is enabled) and tightly coupled with other rtsp messages.

4. As state privately before this drafts need to be checked against the 
ID nits: http://www.ietf.org/ID-nits.html

[g] yes, we should definitely do that thanks.

5. Section 1. The introduction is basically the same as the 
introduction. I would recommend you to write a better more informative 
introduction.

[g] agreed.

6. Section 1. Last sentence: "As all the other report blocks
defined in [1], the streaming report blocks are applicable to
one-to-one or one-to-many applications that generate
RTCP SR or RR reports." This sentence is not really correct. The use of 
the RTCP XR reports is possible in any application sending RTCP.

[g] himm,i am confused i thought that the first sentence covers everything - what is left out? 
So [1] needs to be updated too?

7. Section 2, You talk about AVP, but this extension is not dependent on 
any special profile and seems to be compatible with any of the four 
available or under development profiles that exist.

[g] agreed.

8. Section 2, Figure 1. This figure shows this report formats potential 
need to have reporting from all layers on the receiving side. This might 
be a problem for certain application architectures. I am not saying that 
it can't be used, its only that some applications may have difficulties 
to include your reports.

[g] we believe the statistics reported should be extensible also should be allowed to be ignored. 
So if an end side cannot support it should put simply a zero - what do you think?

9. Section 3.1, first paragraph: "All timestamps reported by the XR 
packet SHALL be RTP timestamps. All durations SHALL be in units of the 
RTP timebase." This definition is not clear, because in applications 
allowing for switching between payload types the rate can change. I 
think that the intention of using the RTP timestamp value for indication 
over what interval which the report covers is a good one. However some 
more consideration over formulation must be done.

[g] valid point - I guess we need to think more about the corner cases.

10. Section 3.3, PAge 5, first bullet after figure 2:
"- at the AVP module: Packet drop and packet errors can sometimes be
detected by incorrect or missing sequence number or checksum. " Do you 
really need to consider bit-errors, the only allowed possibility for 
bit-errors in RTP is if partial checksums are used. Bit-errors surviving 
to the transport layer is the meaning to be caught by the UDP, etc., 
checksum.

[g] there could be cases where bit errors are propagated (e.g. udp lite).

11. Section 6. The streaming metrics should probably have a value to 
combine with the parameter to indicate how often the report block should 
be included. This seem to be a block that is not needed very often.

[g] valid point, note taken.

12. Section 8. The security section does not look sufficient. I guess 
that the consideration for this is rather similar to the VoIP block. 
However I think there should be made some effort to indicate the main 
security concerns also in this document.

[g] agreed.

13. Section 12. The references need to be divided into Normative and 
Informative ones.

[g] agreed.

Cheers

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: [email-masked]

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 06 Nov 2003 08:41:16 +0100

Hi Gamze,

To my knowledge there is no profile dependencies in RFC 3611. Thus it 
can be used for any of the four profiles defined or under definition. My 
comment was to point out this fact and that it seems inappropriate to 
talk about any special profile in this context.

cheers

Magnus

-- 

Magnus Westerlund