RE: continuing the discussion on timestamps

[Raz Gabe <Raz.Gabe@xxxxxxxx>]

Hi Jouni,

Some thoughts on the protocol versions.

The protocol version is OK, but as we know from past, every version should support also legacy version….

Of course it is better that we will try to cover most/all of the needed fields in the first standard post, and reserved fields/bits can help to delay a new version.

A new version might also change the place of some fields (which we will try to eliminate…).

Rgrds

--Raz

 

From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Richard Tse
Sent: Thursday, March 19, 2015 4:00 AM
To: Jouni Korhonen; patrick diamond; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: continuing the discussion on timestamps

 

Jouni:

 

Yes, the protocol version could rightfully be used to identify the presence of a more precise timestamp.

 

My concern is that other new features or information fields may not fit well being identified as a new protocol version and may cause the limited # of protocol versions to be used up very quickly.

Rich

 

From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Wednesday, March 18, 2015 5:03 PM
To: Richard Tse; patrick diamond; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: continuing the discussion on timestamps

 

Richard,

 

We also got space for indicating 4 protocol versions. That added to the reserved bits is not enough? I mean a new protocol version can expand the header outside the reserved bits if needed.

 

- Jouni

 

 

 

From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Richard Tse
Sent: Wednesday, March 18, 2015 4:26 PM
To: patrick diamond; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Cc: Richard Tse
Subject: RE: continuing the discussion on timestamps

 

Jouni:

 

I think 1ns is sufficient for the foreseeable future.  For the unforeseen future, a RESERVED bit could be used to signal the use of a different packet header, which has a timestamp field that supports higher precision.

 

I think we should add more RESERVED bits to the header as, almost certainly, many new features will be created as RoE evolves.

 

Regards,

 

Rich

 

 

From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of patrick diamond
Sent: Wednesday, March 18, 2015 4:04 PM
To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: continuing the discussion on timestamps

 

Jouni
 
Hi. If the timestamp is used only for the playout time and the granularity is 1nS, how will the sending system know the value of time at the receiving system with 1nS granularity for playout planning? How will the sending system know the transit time of that specific packet to plan for the playout with 1nS of accuracy?
 
Pat
 

> From: jouni.korhonen@xxxxxxxxxxxx
> To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> Subject: continuing the discussion on timestamps
> Date: Wed, 18 Mar 2015 22:40:43 +0000
>
> Folks,
>
> Let's continue where we left off in call.. two things I would like to get a better sense of the room is the timestamp granularity/accuracy. I had a proposal for 1ns and not sending timestamp in every packet. Assuming that the timestamp actually serves as a marker when the packet(s) need to be played out from the encapsulation function (e.g. to RE, REC or in some use cases to CPRI mapper - exact location _where_ in encaps/mapper is up to the implementation) I would take 1ns is enough. Between timestamps I proposed using sequence numbers.
>
> Comments? Thoughts?
>
> - Jouni