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

["Tom-PT Taylor" <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt