Subject: [rmcat] Magnus Westerlund's No Objection on draft-ietf-rmcat-nada-12: (with COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 05 Sep 2019 06:57:49 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-rmcat-nada-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A Question regarding Section 5.1.1.

This section recommends using a NADA specific transmission timestamping
mechanism embedded in the transport. What about the header extension for       
Transmission Time offsets? Are there a reason to not discuss using that a
potential solution for providing that. I know it has the downside of being
expressed in RTP payload format timescales and not in a nice and likely more
compact milisecond, but it is a standardized solution that can provide the
necessary signal.

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Fri, 6 Sep 2019 16:41:23 +0000

Hi Magnus, 

Thanks for your review of this draft. 

Regarding your question on transmission timestamping mechanism in Section 5.1.1.: our current implementation
haven't yet considered the Transmission Time offset in header extension, but rather simply generated a timestamp
via local system clock and embedded that information in the transport packet header. 

We've revised the description accordingly, to more accurately describe what the current implementation does and
the potential solution via a standardized format: 

https://tools.ietf.org/html/draft-ietf-rmcat-nada-13 , in Sec. 5.1.1:

	... For experimental implementations, instead of relying on
   	RTP timestamps and the transmission time offset RTP header extension
   	[RFC5450], the NADA sender can generate its own timestamp based on
   	local system clock and embed that information in the transport packet
   	header.  

Best regards,
Xiaoqing

On 9/5/19, 8:58 AM, "Magnus Westerlund via Datatracker" <[email-masked]> wrote: