Subject: [AVT] Re: Review requested: draft-ietf-avt-rtp-toffset-04.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Feb 2007 18:39:06 -0500

Here was Dave's response to Qiaobing's review. I've changed the subject 
line (above) to correlate with the reviews.

Dave Singer wrote:
--------------------

At 11:41  +0000 26/01/07, Colin Perkins wrote:
>
>Qiaobing Xie sent the following comments on the toffset draft:

Thanks, I missed this one.  Here are some proposed responses...

>
>1. I agree with the use case analysis in the draft and agree in 
>general this may be a useful extension.
>
>2. I would like to see a more crisp definition of the "transmission 
>timestamp" - what is it? Is it the time instance the first (or the 
>last) octet of the packet is put on the wire by the physical 
>interface at the RTP sender? Or is it the time instance the sending 
>RTP stack passes the fully assembled packet into the out-going 
>buffer? Or, is it the time instance the last media octet in the 
>packet was assembled at the RTP stack? and so on.

I really don't want to define it any more than the RTP specification
defines it.  This draft merely provides information about it;  its
definition is in 3550.

>
>3. The following statement in the draft:
>
>   "In the RTP specification [RFC3550] it is implied that packets are
>    transmitted essentially in accordance with their RTP timestamps."
>
>is a little misleading since RFC3550 only says:
>
>   "The timestamp reflects the sampling instant of the first octet in
>    the RTP data packet."
>
>I'd therefore suggest to say something like: "RFC 3550 does not 
>specify a transmission timestamp."

But this is missing the point.  It's true that 3550 does not have a
'transmission timestamp' that is different from the media timestamp;
but jitter calculations etc. are all based on the assumption that
they are in 1-1 relationship.

>
>4. The sentence:
>
>   "When added to the RTP timestamp of the packet, it represents the
>    "effective" RTP transmission time of the packet, on the RTP
>    timescale."
>
>seems to say that
>
>   Adjusted RTP timestamp = RTP timestamp in RTP header +
>                            transmission offset
>
>If so, it probably is helpful to spell this out clearly.

More accurately:
RelativeTransmissionTimeinRTPUnits = RTPTimestamp + transmission_offset

>
>5. If my understanding above (point 4) is correct, then I am 
>confused about the following statement:
>
>    "The sign of the offset value depends greatly on the choice of the
>    initial mapping of RTP to NTP times.  In general, without scanning a
>    stream entirely it is not possible to ensure that this mapping would
>    keep all the offsets positive; therefore this specification allows
>    negative values."
>
>Some more explanation would help.

Imagine a stream with the following timestamps and sizes in bytes

200   2kb
300   4kb
400   2kb
500   12kb
600   ...effective end of stream

This has 20KB spread over 400 time units, i.e. on average 1 kb per 20
time-units.  We traffic-smooth this, and establish that given a
transmission time of x for the first packet, we would transmit the
following packets at the given intervals later:

x + 000  2kb
x + 040  4kb
x + 120  2kb
x + 160  12kb
x + 400 ...effective end of stream

The choice of x is esssentially arbitrary:  only relative values of
timestamps matter.  Now, let's say I claim on the first packet that
it went out *at* its RTP timestamp, i.e. with an offset of 0, i.e. x
is 200.   Then the offset values are

0
-60
-80
-140

This is because in this case, I traffic-smooth this because
conceptually I think of sending the small packets 'early'.  But it is
just as valid to say x is 400, whereupon the offset values are

200
140
120
60

>
>6. In section 4, it would help if more detail can be given on how to 
>"indicate the actual network jitter, excluding the source-introduced 
>jitter". An example calculation would help too.

Simply perform the jitter calculation on the 'RTP time of
transmission' defined above...

>
>
>>>>I think we have passed the indicated date without comment, right? 
>>>>So, what happens now?
>>>>
>>>>Thanks, gang
>>
>>
>>--
>>David Singer
>>Apple Computer/QuickTime
>
>--
>Colin Perkins
>http://csperkins.org/

-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Feb 2007 18:43:01 -0500

Here is Colin's response to Dave's note. Again, the subject line was 
changed to correlate with the previous messages I sent on.

I do apologize for the inefficiency of all this. I've learned a few 
lessons for the next set of documents I shepherd through Last Call.

Tom

Colin Perkins wrote:
-----------------------

On 29 Jan 2007, at 10:28, Dave Singer wrote:
>> 2. I would like to see a more crisp definition of the  
>> "transmission timestamp" - what is it? Is it the time instance the  
>> first (or the last) octet of the packet is put on the wire by the  
>> physical interface at the RTP sender? Or is it the time instance  
>> the sending RTP stack passes the fully assembled packet into the  
>> out-going buffer? Or, is it the time instance the last media octet  
>> in the packet was assembled at the RTP stack? and so on.
>
> I really don't want to define it any more than the RTP  
> specification defines it.  This draft merely provides information  
> about it;  its definition is in 3550.

Agreed.

> 'transmission timestamp' that is different from the media  
> timestamp; but jitter calculations etc. are all based on the  
> assumption that they are in 1-1 relationship.

Kind-of... The jitter calculation breaks if the transmission time
doesn't have a one-to-one mapping onto the sampling instant, but I
don't think 3550 mandates such a mapping.

...snip the rest, which seems reasonable...

-- 
Colin Perkins
http://csperkins.org/

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Feb 2007 18:46:31 -0500

Here is what I hope is the last word on the topic: Dave's actions.

Dave Singer wrote:
-------------------

OK, changed the first sentence:

In the RTP specification <xref target="RFC3550"/> network jitter
calculations are based on the presumption that packets are
transmitted essentially in accordance with their RTP timestamps.

and added

The RTP specification does not define a transmission timestamp, and
nor does this specification.  This specification merely provides
information on the relationship between the relative transmission
times and relative RTP timestamps.

and

The reported transmission time T1 of a packet with timestamp R1 and
an offset of O1, from the above equations, is T1 = R1+O1 (though of
course the transmission time values only have meaning when two or
more are compared).

and

The content is exactly that number of interarrival jitter
calculations, calculated using the same formula as for sender and
receiver reports, but taking into account the transmission offsets
for the streams (if any);  that is, using the values T1=R1+O1, T2
etc. as defined above, instead of R1, R2 etc..

I then re-named the symbols to be in accord with the RTP spec (i.e.
using Si for RTP timestamp, not Ri).

---

From: Qiaobing Xie <[email-masked]>
Date: Sun, 11 Feb 2007 15:11:57 -0600

I agree. The proposed changes address my comments sufficiently.

regards,
-Qiaobing

Tom-PT Taylor wrote:
> ------------------------------------------------------------------------
>