Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jul 2013 13:54:20 -0700

Thanks.

I neglected to send this to a few other folks initially.

On 10 July 2013 00:51, Stokking, H.M. (Hans) <[email-masked]> wrote:
> Dear Martin,
>
> Ray is out-of-office at the moment, I'll discuss your comments with him when he gets back next week. We'll let you know how we expect to deal with your comments then.
>
> Best regards, Hans
>
> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: maandag 8 juli 2013 19:38
> To: [email-masked]
> Subject: AppsDir review of draft-ietf-avtcore-idms-09
>
> I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft.  (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments you may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>
>
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Martin Thomson
> Review Date: 2013-07-08
> IETF Last Call Date: ?
> IESG Telechat Date: ?
>
> Summary: This document is almost ready for publication as proposed standard.  There are a few minor issues.
>
>
> Section 6.
> Is there a strong reason for the MSAS to be placed at the RTP sender?
> Based on the description provided, this function can be independent, with the exception that it be necessary to receive RTCP reports.  The description in 6.1 omits the information that would be necessary to conclude that it is in the right place (i.e., it receives RTCP IDMS XR reports, and sends RTCP IDMS messages.)
>
> There is also a third potential role in this scenario, which is probably also assumed by an actual RTP sender.  In a network with large disparity of network delays and playback occurring on devices with limited capacity, is it not also possible - or even necessary - for an RTP sender to perform some buffering to add delay?
>
> Section 7 re: Synchronization Packet Sender Type .
>
> I'm not finding any motivation for the inclusion of this field and I can't infer from the text what its purpose is.  I think that the document needs something here.  I notice that removing it would allow you to remove 32-bits from the payload.
>
> Section 7 re: Packet Presented NTP timestamp: 32 bits.
>
> The description of this parameter requires special handling with respect to epoch and rollover.  I might assume that it is within 2^16 seconds of the received timestamp, but always greater.
>
> There are other ways to encode this information, though.  Since this is always strictly after a packet is received, then encoding a delta might also be possible.  That would set the epoch for this field to the packet received NTP timestamp and avoid any rollover issues (though it would limit the amount of buffering delay to 2^16).
>
> Section 11.
> This ABNF implies that the 'a' in 'a=rtcp-idms' is case-insensitive.
> This is not permitted by RFC 4566.
>
> Note that you should also specify 'decimal' rather than 'numerical' in the description, assuming of course that you want decimal numbers.
> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 16 Jul 2013 09:43:02 +0000

Hi Martin,

Thanks for the thorough review. Please see my comments inline. 

Best regards,

Ray

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: donderdag 11 juli 2013 22:54
To: Stokking, H.M. (Hans)
Cc: [email-masked]; IETF Apps Discuss; The IESG
Subject: Re: AppsDir review of draft-ietf-avtcore-idms-09

Thanks.

> Based on the description provided, this function can be independent, with the exception that it be necessary to receive RTCP reports.  The description in 6.1 omits the information that would be nec…

Yes, you're right, an MSAS could be independent from the RTP Sender as long as it receives the necessary RTCP reports and the RTP stream itself to correlate reports from different receivers. It could even be located in one of the RTP Receivers (as noted in section 6). I will add a few sentences to 6.1 to clarify this. 

> There is also a third potential role in this scenario, which is probably also assumed by an actual RTP sender.  In a network with large disparity of network delays and playback occurring on devices…

You're right that the current system assumes RTP receivers have large enough buffers to delay the received streams. In theory it would be possible to have the RTP sender add delay as well, although this would add considerable complexity to the system and only be useful in a limited set of scenarios. For example, such a system will not work well in multicast environments. In addition, having to coordinate buffer delays between multiple parties is very complex. 

> I'm not finding any motivation for the inclusion of this field and I can't infer from the text what its purpose is.  I think that the document needs something here.  I notice that removing it would…

There are two motivations behind the SPST field. Firstly, it allows for extensions to the IDMS mechanism without having to specify new XR blocks. Secondly, it allows for compatibility with the ETSI TISPAN spec (see section 2.2 of the -11 version of the draft). 

> There are other ways to encode this information, though.  Since this is always strictly after a packet is received, then encoding a delta might also be possible.  That would set the epoch for this…

In the WG we have had some discussion whether we should have a 32-bit or 64-bit NTP timestamp here. In the end, consensus was that a 32-bit timestamp would be sufficient for the XR Report, while we included a 64-bit timestamp in the RTCP Settings packet. You're right that we're assuming the delay to be within 2^16 seconds. I will add a note to the text to make this explicit. 

> This is not permitted by RFC 4566.

I'm not an ABNF expert, are you proposing to change the 'a' into %d97? I've browsed through various recent MMUSIC and AVTCORE documents, and they all seem to use the 'a' notation. 

> Note that you should also specify 'decimal' rather than 'numerical' in the description, assuming of course that you want decimal numbers.

I assume you mean the line 'SyncGroupId = 1*10DIGIT ; Numerical value from 0 through 4294967294'? I will change this is the next iteration. 

Thanks again,

Ray

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jul 2013 12:04:58 -0700

Thanks Ray,

It looks like you got most of what I was concerned about.  I will
await a -12 revision.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jul 2013 02:32:42 -0700

The new version addresses my concerns.  Looks good.  Thanks Ray.