Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

[Qin Wu <[e-mail]>]

----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "IETF AVTCore WG" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 03, 2011 9:48 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04


> Hi,
> 
> Removing all issues that don't need additional discussion or commenting.
> 
> 
> 
> On 2011-10-25 07:45, Qin Wu wrote:
>> 
>> 9. Section 4:
>> "It is also
>>       fixed across multiple RTP sessions from the same source."
>> 
>> I interpret "source" in the above as an end-point or RTP node. Which
>> causes me to have the following comment.
>> 
>> This is very commonly true, but not universally true. As CNAME
>> identifies a synchronziation context, a given end-point could have media
>> sources that belong to multiple synchronization contexts in the same
>> session. For example have microphones and cameras from multiple rooms,
>> where each room will be its own synchronization context.
>> 
>> 
>> 
>> [Qin]: Agree with your thinking, but here what we emphasize is "across multiple RTP session"
>> 
>> Does this really conflict with what you said?
>> 
>> Anyway I will reword this in the new vesion.
>> 

> No, as long as we consider source as media recording device(s) in a
> given synchronization context they will be fixed across multiple sessions.
> 


[Qin]: Okay, do we have other use cases besides the above one you gave?

>> 
>> 12. Section 4. bullet 3:
>> This issues does not have a recommendation in the next section. I think
>> we should document the WG consensus on this issue. Even if it was that
>> this issue wasn't significant enough to do something about. Or am I
>> remembering the WG consensus wrong?
>> 
>> 
>> 
>> [Qin]: Yes, the issue wasn't significant and I remembered the consensus is 
>> 
>> to replace tag with the SSRC and use SSRC to identify and correlate and group
>> 
>>  participants between reports. The sequence numbering information and
>> 
>>  measurement interval can be defined in a new RTCP XR block if needed, 
>> 
>> but is not related to identity. Therefore I will add one section to talk about how to deal with this issue.
>> 
> 
> Thanks, I think it is strange if we don't document the consensus
> resolution when it is listed as an issue.

[Qin]: Yes, I have documented them in the new version 05 I submitted before the deadline.

>> 
>> 21. Section 7.1:
>> 
>> Strictly the RTP end
>>    system can only conclude that its RTP has been lost in the network,
>>    though an RTP end system complying with the robustness principle of
>>    [RFC1122] should survive with essential functions unimpaired.
>> 
>> What is the purpose with this sentence? And what is actually seen as
>> "essential functions"?
>> 
>> 
>> 
>> [Qin]: I think essential functions are referred to as "media distribution"
> 
> So you mean that a robustly built end-point will still be able to send
> its media despite the fact that media it should receive has been lost in
> between the sender and this receiver?

[Qin]: That's my understanding, is that okay with you?

>> 
>> 22. Section 7.2:
>> For bidirectional unicast, an RTP system may usually detect RTCP XR
>>    from a translator by noting that the sending SSRC is not present in
>>    any RTP media packet.
>> 
>> So the assumption here is that the translator has its own SSRC to send
>> these monitoring reports. But, how does an RTP node determine that an
>> SSRC is associated with a translator rather than a receiver only
>> end-point? From a session participant I don't think you can determine if
>> a give SSRC is a receiver or just a monitor. They will not look
>> different. One needs session configuration information, and in that case
>> configuration information where the translator announces its node type
>> to the management system.
>> 
>> 
>> 
>> [Qin]: That's what I want to said in part. And I agree that node type should also be announced.
>> 
>> I will revise the draft to reflect this.
> 
> Ok, I think the new text is good enough.

[Qin]: Thanks.

>> 
>> 23. Section 8. I agree that this draft shouldn't have a IANA
>> Consideration other to say that it is has no actions. However, I think
>> the document should consider if it has some guidance on IANA actions for
>> the monitoring architecture. Some part of this is clearly about the
>> consumption of XR block code points that isn't a major issue. And if we
>> do run out a second RTCP packet type for XR block 2 could be assigned.
>> 
>> 
>> 
>> [Qin]: The WG consensus is space depletion is not issue
>> 
>> if you really want space expansion, you can define one XR block type
>> 
>>  for vendor-specific extensions, with an enterprise number included 
>> 
>> to identify the vendor making the extension. So I prefer to say
>> 
>> "There is no IANA action in this document"
> 
> Yes, but if that is the conclusion, shouldn't we document it?

[Qin]: Okay, I can put them in the new version.

> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>