Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

[Kevin Gross <[e-mail]>]

Dan, thanks for looking at this.

As a co-author, I'll weigh in on a couple of things that Ray did not
address.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <
[e-mail]> wrote:

>
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> Sent: zondag 9 juni 2013 9:53
> To: General Area Review Team
> Cc: [e-mail]
> Subject: Gen-ART review of draft-ietf-avtcore-idms-09
>
> (resending, I mis-spelled .all address at the first try)
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Dan Romascanu
> Review Date: 6/6/13
> IETF LC End Date: 6/11/13
> IESG Telechat date:
>
> Summary:
>
> Not Ready
>
> Major issues:
>
> 5. In Section 8:
>
>    Because RTP
>    timestamps do wrap around, the sender of this packet SHOULD use
>    recent values, i.e. choose NTP timestamps that reflect current time
>    and not too far in the future or in the past.
>
> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
>
> [Ray: I will check with my co-authors]
>

[Kevin] Devices that receive these reports need to deal with rollover
conditions both for the RTP timestamp (which can rollover a couple times a
day) and the NTP timestamp (which will have its first rollover in 2036). I
believe these requirements are already stated in RFC3550 and RFC5905
respectively. The suggestion to use recent timestamps in reporting reduces
statistical chance that a receiving device will need to do extra
computation required to handle an RTP rollover. There's no way to eliminate
this possibility altogether and the requirement is stated in a qualitative
way and so could not be enforced as a MUST.

>
> 6. In Section 8:
>
>    This SHOULD relate to the first
>    arriving RTP packet containing this particular RTP timestamp, in case
>    multiple RTP packets contain the same RTP timestamp.
>
> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
>
> [Ray: I will check with my co-authors]
>

[Kevin] This is an issue that the authors discussed at length and for which
we do not believe there is an optimal solution and so we were reluctant to
require our recommendation. Ideally we want an NTP timestamp indicating
when all data required to render the specified RTP timestamp has arrived.
For this we'd really like to know when the last packet for an RTP timestamp
arrived. In the presence packet loss and reordering, it is not possible to
reliably record the last packet. It is possible to record the first packet
and so this is our recommendation. The accuracy of arrival times is not so
critical in IDMS as arrival time allows a less precise synchronization than
presentation times.