Subject: [AVT] draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt

From: Nikolai Leung <[email-masked]>
Date: Thu, 09 Mar 2006 01:47:02 -0500

All,

We have submitted the Internet-Draft 
draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt.  Until it becomes available in 
the archives you can get a copy at:

http://www.ietf.org/internet-drafts/draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt

We would appreciate your review and comments.

Thanks,

Nik Leung  

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

---

From: [email-masked]
Date: Thu, 9 Mar 2006 09:19:31 +0100 (CET)

Folks,

this draft sounds like being written in the context of the "Jitter Buffer
Management" work ongoing in 3GPP and 3GPP2.  Nik, can you confirm this?

As for the technical quality, the draft appears to lack the (rather
complex) discussions of multicast scenarios, which created so much trouble
in the CCM draft.  I'm not sure that the draft addresses multiple
receivers adaequately (likely not), and I'm fairly certain that it does
not address multiple sender scenarios at all.  I guess this needs to be
fixed in future versions.

It would also be advisable, that future versions would be aligned with the
recent CCM draft structure.

Regards,
Stephan

> Nik Leung  _______________________________________________

---

From: David R Oran <[email-masked]>
Date: Fri, 10 Mar 2006 08:44:44 -0500

I have an even more basic question. If all you're trying to do is  
report late packets (due to congestion or whatever), why don't the  
existing RTCP receiver reports suffice?

On Mar 9, 2006, at 3:19 AM, [email-masked] wrote:

>> draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt.  Until it becomes  
>> available
>> in

---

From: Nikolai Leung <[email-masked]>
Date: Mon, 13 Mar 2006 16:25:08 -0500

>Management" work ongoing in 3GPP and 3GPP2.  Nik, can you confirm this?

Stephan,

We are thinking of using these messages for the Packet Switched Video 
Telephony "rate adaptation" work in 3GPP and 3GPP2.  The PDAR message 
provides information about congestion experienced by the receiver that the 
RTP sender can use to adapt its rate.

>fixed in future versions.

Our interest in the messages was not for multi-point scenarios but rather 
point-to-point conversational services.  However, we can address the 
multi-point scenarios if there is interest among the AVT membership.

>recent CCM draft structure.

We are amenable to this.  We based our draft on the earlier -01 version of 
the CCM draft.  We'll look over the latest CCM draft structure to see what 
can be aligned.

Thanks,

-Nik

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Mar 2006 10:24:56 +0100

Hi Nikolai,

I have looked at this draft an do question the usability of having the 
receiver request that delivery is done earlier. Lets look how things 
usually are done and why.

In a conversational case, i.e. minimal delay is the target, the sender 
encodes, packetize and transmit as soon as it can, while avoiding 
congestion. The packet-based (normally best-effort) network transports 
the packet from the sender to one or more receivers. The receivers uses 
a jitter-buffer to cope with the variation of the time it takes from 
sampling until removal from the buffer.

In those cases you have multiple receivers not doing a receiver side 
adaptation to the jitter and delivery delay seems really problematic. 
Where a receiver can adopt to its individual situation, a sender need to 
take all receivers into account.

Even in a single receiver use case, the request for adjusting the packet 
delay may be impossible to react to. If a receiver request the sender to 
send the packets earlier so that they arrive in time, that means that 
the sender is capable of moving the transmission to earlier. In many 
case it is already running a minimal delay setup from sampling until 
transmission. Thus the receiver is not capable of moving the schedule 
earlier.

I also think it is important to consider where is the delay between the 
transmitter and receiver coming from? I think we can break it up into 
static delay that can't vary, like the propagation delay through the 
medium. However the static delay is not really guaranteed to not change 
in an IP network. If you have a route change for your traffic then your 
delay may change. Then there is the varying delay, caused by for example 
buffer levels in the routers. In the case of mobile radio networks it 
may also be caused by radio link layer retransmission or the HSDPA 
scheduler. So we do have several effects in play, some which is 
congestion dependent.

As I see it requesting changes in the delay is not really productive. 
The thing the sender do have partial control over is the congestion 
situation. Thus it seems primarily be of interest to combat congestion. 
For that I think there is better indicators than a request to adjust the 
delay.

So can you please explain why PDAR is a good mechanism?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Nikolai Leung <[email-masked]>
Date: Tue, 14 Mar 2006 16:25:20 -0500

>existing RTCP receiver reports suffice?

David,

The receiver report format defined in RFC 3550 does not include any fields 
that allow the receiver to indicate how late packets are arriving at the 
receiver.  Was there a particular field/extension that you had in mind?

Regards,

-Nik

---

From: David R Oran <[email-masked]>
Date: Tue, 14 Mar 2006 16:28:57 -0500

On Mar 14, 2006, at 4:25 PM, Nikolai Leung wrote:

> The receiver report format defined in RFC 3550 does not include any  
> fields that allow the receiver to indicate how late packets are  
> arriving at the receiver.  Was there a particular field/extension  
> that you had in mind?
>
Yes, inter-arrival jitter plus lost packets is a pretty good indicator.

>>>> http://www.ietf.org/internet-drafts/draft-hdesineni-avt-avpf- 
>>>> ccm- pd-extn-00.txt
>>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Mar 2006 11:26:34 +0100

Hi Nikolai,

Thanks for this clarifying email. I do however still have a few comments 
on this.

So your proposed mechanism is in fact a receiver to sender notification 
on the receiver perceived changes in the delay between the sender and 
receiver. The issue I see in this is the aggregation of all effects that 
cause delay changes and jitter. The delay consists of so many 
components. If they could be seen only as static delay and variable 
congestion dependent delay then it would be an excellent indication of 
congestion. However it is the part that is non-congestion related delay 
changes or jitter. There is also the issue of delayed transmission that 
an RTP receiver totally lacks information about. Due to the lack of 
transmission timestamping of RTP packets, a receiver is unable to 
determine anything for certain about the transport delay between the 
sender and the receiver.

I hope you also reviewed the existing mechanism for measuring delay or 
arrival jitter that exist in the RTP/RTCP framework. The TTL 
measurements in RTCP (RFC 3550) and the extended reports available in 
RFC 3611. These mechanism is intended to allow the sender to determine 
the round-trip time and compare the actual arrival times to its 
transmission times, that way it can determine changes in the 
transmission delay between packets.

Cheers

Magnus

Nikolai Leung wrote:
> Hi Magnus,
> 
> One of the problems with the usual method of having only the receiver 
> adjust its de-jitter buffer and play out times based on the arrival of 
> traffic is that,
> 
> 1.  In wireless systems like HSDPA/HRPD where a single down/forward link 
> channel is shared among all the users in the cell and assigned by the 
> scheduler to users based on their individual down/forward link quality, 
> the E2E delays of packets can vary significantly at different locations 
> in a cell and under different loading conditions (i.e., # users in the 
> cell).  It is important to note that the variation in E2E (down/forward 
> link) delays at different locations is the result of changes in the link 
> throughput because of variations in the radio link quality.  The 
> instantaneous data rate assigned to a user is based on what can be 
> supported by the radio link at that location.  As this changes, so does 
> the delivery time for packets of a particular size.
> 
> In the attached slide the dashed lines show the distribution of average 
> E2E delays for packet-switched video telephony users being served in 57 
> cells by a HSDPA/HRPD-type of scheduler in each cell.  Note that in the 
> simulations there are a significant # of users who experience an E2E 
> delay of over 600ms.  The number of users seeing longer delays gets 
> worse as the loading in the cells increases (i.e., going from 8 to 12 
> users/cell).
> 
> 2.  To accommodate for these variations, a receiver can use a very deep 
> (long) de-jitter buffer to accommodate for this significant variation in 
> E2E delays.  However this produces a long static E2E delay as a static 
> de-jitter buffer will have to accommodate for the longest E2E delay the 
> receiver expects to receive.  In the cases we are seeing, the longest 
> E2E delay can exceed what is acceptable for conversational services.
> 
> 3.  The receiver can also do adaptive de-jitter buffering and adapt its 
> play out times based on the arrival times of packets.  While this allows 
> the receiver to adapt to shorter E2E conditions when in good link 
> quality (closer to the base station) or lightly loaded cells, it still 
> suffers from the problem that as the user moves further away from the 
> base station or more users enter the cell the user will experience 
> unacceptably long delays for conversational services.  Again this can be 
> seen in the attached figure.
> 
> PDAR Message
> 
> The PDAR message allows terminals to still perform de-jitter buffer/play 
> out time management based on packet arrivals.  But it also introduces a 
> procedure to tell the sender the status of arrivals at the receiver.  We 
> are establishing a control loop between the sender and receiver that 
> allows the receiver to better control the play out times of the media 
> (and not simply react to what it receives from the sender).
> 
> For example, as packets are starting to arrive delayed (i.e. closer to 
> their play out times at the receiver) the receiver can start to delay 
> its play out times and also indicate to the sender that packets are 
> arriving later (and by how much) than the receiver requires.
> 
> I think there might be some confusion about the PDAR since we called it 
> a "Request."  It does not request that packets be sent earlier by the 
> sender since as you point out this is usually not possible.  It is an 
> indication to the sender that the receiver is not receiving its packets 
> at the desired time for play out (and by how much).  The sender is to 
> interpret this indication to mean that the link rate may be too slow 
> and/or congestion from cell loading too heavy to support the current 
> rate it is transmitting at.
> 
> In summary, the PDAR is an indication of the receiver's play out 
> situation as it is affected by the
> + link speed/quality
> + congestion
> + sender's packet sizes/sending rate
> 
> The sender can use the PDAR to adjust its output rate (essentially 
> decrease its frame/packet sizes) to get its transmission through the 
> slower link more quickly and address the play out situation at the 
> receiver.  We think this is a good control-loop feedback variable since 
> it is directly linked to the play out times of the receiver, and thus 
> directly controls the quality rendered to the user.
> 
> The solid lines in the attached figure show the results of feeding back 
> this packet delay information to the senders of point-to-point packet 
> switched video telephony calls.  The senders adjust their transmitted 
> video frame sizes (video QP values) based on this delay information and 
> are able to adapt well to the variations in link and loading 
> conditions.  Most of the E2E delays are centered around 150ms as opposed 
> to the dashed lines where E2E delays peak around 620ms and can range up 
> to 1000ms.
> 
> What are the other congestion indicators that you were thinking of?
> 
> Regards,
> 
> -Nik
> 
> 
> At 04:24 AM 3/14/2006, ext Magnus Westerlund wrote:
>> Hi Nikolai,
>>
>> the packet from the sender to one or more receivers. The receivers 
>> uses a jitter-buffer to cope with the variation of the time it takes 
>> from sampling until removal from the buffer.
>>
>> Where a receiver can adopt to its individual situation, a sender need 
>> to take all receivers into account.
>>
>> Even in a single receiver use case, the request for adjusting the 
>> packet delay may be impossible to react to. If a receiver request the 
>> sender to send the packets earlier so that they arrive in time, that 
>> means that the sender is capable of moving the transmission to 
>> earlier. In many case it is already running a minimal delay setup from 
>> sampling until transmission. Thus the receiver is not capable of 
>> moving the schedule earlier.
>>
>> I also think it is important to consider where is the delay between 
>> the transmitter and receiver coming from? I think we can break it up 
>> into static delay that can't vary, like the propagation delay through 
>> the medium. However the static delay is not really guaranteed to not 
>> change in an IP network. If you have a route change for your traffic 
>> then your delay may change. Then there is the varying delay, caused by 
>> for example buffer levels in the routers. In the case of mobile radio 
>> networks it may also be caused by radio link layer retransmission or 
>> the HSDPA scheduler. So we do have several effects in play, some which 
>> is congestion dependent.
>>
>> situation. Thus it seems primarily be of interest to combat 
>> congestion. For that I think there is better indicators than a request 
>> to adjust the delay.
>>

-- 

Magnus Westerlund

---

From: Nikolai Leung <[email-masked]>
Date: Tue, 14 Mar 2006 20:15:50 -0500

Hi Magnus,

1.  In wireless systems like HSDPA/HRPD where a single down/forward link 
channel is shared among all the users in the cell and assigned by the 
scheduler to users based on their individual down/forward link quality, the 
E2E delays of packets can vary significantly at different locations in a 
cell and under different loading conditions (i.e., # users in the 
cell).  It is important to note that the variation in E2E (down/forward 
link) delays at different locations is the result of changes in the link 
throughput because of variations in the radio link quality.  The 
instantaneous data rate assigned to a user is based on what can be 
supported by the radio link at that location.  As this changes, so does the 
delivery time for packets of a particular size.

In the attached slide the dashed lines show the distribution of average E2E 
delays for packet-switched video telephony users being served in 57 cells 
by a HSDPA/HRPD-type of scheduler in each cell.  Note that in the 
simulations there are a significant # of users who experience an E2E delay 
of over 600ms.  The number of users seeing longer delays gets worse as the 
loading in the cells increases (i.e., going from 8 to 12 users/cell).

2.  To accommodate for these variations, a receiver can use a very deep 
(long) de-jitter buffer to accommodate for this significant variation in 
E2E delays.  However this produces a long static E2E delay as a static 
de-jitter buffer will have to accommodate for the longest E2E delay the 
receiver expects to receive.  In the cases we are seeing, the longest E2E 
delay can exceed what is acceptable for conversational services.

3.  The receiver can also do adaptive de-jitter buffering and adapt its 
play out times based on the arrival times of packets.  While this allows 
the receiver to adapt to shorter E2E conditions when in good link quality 
(closer to the base station) or lightly loaded cells, it still suffers from 
the problem that as the user moves further away from the base station or 
more users enter the cell the user will experience unacceptably long delays 
for conversational services.  Again this can be seen in the attached figure.

PDAR Message

The PDAR message allows terminals to still perform de-jitter buffer/play 
out time management based on packet arrivals.  But it also introduces a 
procedure to tell the sender the status of arrivals at the receiver.  We 
are establishing a control loop between the sender and receiver that allows 
the receiver to better control the play out times of the media (and not 
simply react to what it receives from the sender).

For example, as packets are starting to arrive delayed (i.e. closer to 
their play out times at the receiver) the receiver can start to delay its 
play out times and also indicate to the sender that packets are arriving 
later (and by how much) than the receiver requires.

I think there might be some confusion about the PDAR since we called it a 
"Request."  It does not request that packets be sent earlier by the sender 
since as you point out this is usually not possible.  It is an indication 
to the sender that the receiver is not receiving its packets at the desired 
time for play out (and by how much).  The sender is to interpret this 
indication to mean that the link rate may be too slow and/or congestion 
from cell loading too heavy to support the current rate it is transmitting 
at.

In summary, the PDAR is an indication of the receiver's play out situation 
as it is affected by the
+ link speed/quality
+ congestion
+ sender's packet sizes/sending rate

The sender can use the PDAR to adjust its output rate (essentially decrease 
its frame/packet sizes) to get its transmission through the slower link 
more quickly and address the play out situation at the receiver.  We think 
this is a good control-loop feedback variable since it is directly linked 
to the play out times of the receiver, and thus directly controls the 
quality rendered to the user.

The solid lines in the attached figure show the results of feeding back 
this packet delay information to the senders of point-to-point packet 
switched video telephony calls.  The senders adjust their transmitted video 
frame sizes (video QP values) based on this delay information and are able 
to adapt well to the variations in link and loading conditions.  Most of 
the E2E delays are centered around 150ms as opposed to the dashed lines 
where E2E delays peak around 620ms and can range up to 1000ms.

Regards,

-Nik

At 04:24 AM 3/14/2006, ext Magnus Westerlund wrote:
>congestion. The packet-based (normally best-effort) network transports the 
>packet from the sender to one or more receivers. The receivers uses a 
>jitter-buffer to cope with the variation of the time it takes from 
>send the packets earlier so that they arrive in time, that means that the 
>sender is capable of moving the transmission to earlier. In many case it 
>is already running a minimal delay setup from sampling until transmission. 
>Thus the receiver is not capable of moving the schedule earlier.
>
>medium. However the static delay is not really guaranteed to not change in 
>an IP network. If you have a route change for your traffic then your delay 
>may change. Then there is the varying delay, caused by for example buffer 
>levels in the routers. In the case of mobile radio networks it may also be 
>caused by radio link layer retransmission or the HSDPA scheduler. So we do 
>have several effects in play, some which is congestion dependent.
>
>As I see it requesting changes in the delay is not really productive. The 
>thing the sender do have partial control over is the congestion situation. 
>Thus it seems primarily be of interest to combat congestion. For that I 
>think there is better indicators than a request to adjust the delay.
>

---

From: David R Oran <[email-masked]>
Date: Wed, 15 Mar 2006 09:49:35 -0500

Don't we have a "late packets" counter in RTCP-XR? That would do the  
trick, wouldn't it?

On Mar 14, 2006, at 8:15 PM, Nikolai Leung wrote:

> Hi Magnus,
>
> One of the problems with the usual method of having only the  
> receiver adjust its de-jitter buffer and play out times based on  
> the arrival of traffic is that,
>
> 1.  In wireless systems like HSDPA/HRPD where a single down/forward  
> link channel is shared among all the users in the cell and assigned  
> by the scheduler to users based on their individual down/forward  
> link quality, the E2E delays of packets can vary significantly at  
> different locations in a cell and under different loading  
> conditions (i.e., # users in the cell).  It is important to note  
> that the variation in E2E (down/forward link) delays at different  
> locations is the result of changes in the link throughput because  
> of variations in the radio link quality.  The instantaneous data  
> rate assigned to a user is based on what can be supported by the  
> radio link at that location.  As this changes, so does the delivery  
> time for packets of a particular size.
>
> In the attached slide the dashed lines show the distribution of  
> average E2E delays for packet-switched video telephony users being  
> served in 57 cells by a HSDPA/HRPD-type of scheduler in each cell.   
> Note that in the simulations there are a significant # of users who  
> experience an E2E delay of over 600ms.  The number of users seeing  
> longer delays gets worse as the loading in the cells increases  
> (i.e., going from 8 to 12 users/cell).
>
> 2.  To accommodate for these variations, a receiver can use a very  
> deep (long) de-jitter buffer to accommodate for this significant  
> variation in E2E delays.  However this produces a long static E2E  
> delay as a static de-jitter buffer will have to accommodate for the  
> longest E2E delay the receiver expects to receive.  In the cases we  
> are seeing, the longest E2E delay can exceed what is acceptable for  
> conversational services.
>
> 3.  The receiver can also do adaptive de-jitter buffering and adapt  
> its play out times based on the arrival times of packets.  While  
> this allows the receiver to adapt to shorter E2E conditions when in  
> good link quality (closer to the base station) or lightly loaded  
> cells, it still suffers from the problem that as the user moves  
> further away from the base station or more users enter the cell the  
> user will experience unacceptably long delays for conversational  
> services.  Again this can be seen in the attached figure.
>
> PDAR Message
>
> The PDAR message allows terminals to still perform de-jitter buffer/ 
> play out time management based on packet arrivals.  But it also  
> introduces a procedure to tell the sender the status of arrivals at  
> the receiver.  We are establishing a control loop between the  
> sender and receiver that allows the receiver to better control the  
> play out times of the media (and not simply react to what it  
> receives from the sender).
>
> For example, as packets are starting to arrive delayed (i.e. closer  
> to their play out times at the receiver) the receiver can start to  
> delay its play out times and also indicate to the sender that  
> packets are arriving later (and by how much) than the receiver  
> requires.
>
> I think there might be some confusion about the PDAR since we  
> called it a "Request."  It does not request that packets be sent  
> earlier by the sender since as you point out this is usually not  
> possible.  It is an indication to the sender that the receiver is  
> not receiving its packets at the desired time for play out (and by  
> how much).  The sender is to interpret this indication to mean that  
> the link rate may be too slow and/or congestion from cell loading  
> too heavy to support the current rate it is transmitting at.
>
> decrease its frame/packet sizes) to get its transmission through  
> the slower link more quickly and address the play out situation at  
> the receiver.  We think this is a good control-loop feedback  
> variable since it is directly linked to the play out times of the  
> receiver, and thus directly controls the quality rendered to the user.
>
> The solid lines in the attached figure show the results of feeding  
> back this packet delay information to the senders of point-to-point  
> packet switched video telephony calls.  The senders adjust their  
> transmitted video frame sizes (video QP values) based on this delay  
> information and are able to adapt well to the variations in link  
> and loading conditions.  Most of the E2E delays are centered around  
> 150ms as opposed to the dashed lines where E2E delays peak around  
> 620ms and can range up to 1000ms.
>
>> I have looked at this draft an do question the usability of having  
>> the receiver request that delivery is done earlier. Lets look how  
>> things usually are done and why.
>>
>> In a conversational case, i.e. minimal delay is the target, the  
>> sender encodes, packetize and transmit as soon as it can, while  
>> avoiding congestion. The packet-based (normally best-effort)  
>> network transports the packet from the sender to one or more  
>> receivers. The receivers uses a jitter-buffer to cope with the  
>> variation of the time it takes from sampling until removal from  
>> the buffer.
>>
>> In those cases you have multiple receivers not doing a receiver  
>> side adaptation to the jitter and delivery delay seems really  
>> problematic. Where a receiver can adopt to its individual  
>> situation, a sender need to take all receivers into account.
>>
>> packet delay may be impossible to react to. If a receiver request  
>> the sender to send the packets earlier so that they arrive in  
>> time, that means that the sender is capable of moving the  
>> transmission to earlier. In many case it is already running a  
>> minimal delay setup from sampling until transmission. Thus the  
>> receiver is not capable of moving the schedule earlier.
>>
>> I also think it is important to consider where is the delay  
>> between the transmitter and receiver coming from? I think we can  
>> break it up into static delay that can't vary, like the  
>> propagation delay through the medium. However the static delay is  
>> not really guaranteed to not change in an IP network. If you have  
>> a route change for your traffic then your delay may change. Then  
>> there is the varying delay, caused by for example buffer levels in  
>> the routers. In the case of mobile radio networks it may also be  
>> caused by radio link layer retransmission or the HSDPA scheduler.  
>> So we do have several effects in play, some which is congestion  
>> dependent.
>>
>> As I see it requesting changes in the delay is not really  
>> productive. The thing the sender do have partial control over is  
>> the congestion situation. Thus it seems primarily be of interest  
>> to combat congestion. For that I think there is better indicators  
>> than a request to adjust the delay.
>>
> <PDAR Adaptation.ppt>

---

From: Nikolai Leung <[email-masked]>
Date: Wed, 15 Mar 2006 20:41:34 -0500

David,

I found these unsuitable for the following reasons:

1.  Inter-arrival jitter

Since RFC 3550 defines the interarrival jitter to be "the mean deviation 
(smoothed absolute value) of the difference D in packet spacing at the 
receiver compared to the sender for a pair of packets." this statistic can 
not be used to determine whether packets are becoming more delayed or 
advanced.  If link/congestion conditions improve such that packets start 
arriving earlier, the inter-arrival jitter value will be a positive 
number.  A positive number will also result when the link/congestion 
conditions degrade and cause delayed packets.

Also, while a link is slowing down, the interarrival-jitter will be 
positive since packet arrivals are decelerating.  However, once the link 
reaches a lower steady-state rate, packet arrivals will stop decelerating 
and interarrival-jitter caused by variations in the link speed will be 
zero.  The packets will all be about equally delayed and this will not 
reflect in the inter-arrival jitter.

In summary, the interarrival jitter measures the mean (absolute) deviation 
of the E2E delay.  It does not measure the mean E2E delay which is what we 
are interested in adapting/controlling.

2.  Lost Packets

One problem is that for some links (such as wireless) packet loss could be 
caused by incorrectly received packets (e.g., lost at the radio layer).  So 
this statistic does not just reflect the number of delayed packets.

Also, for intermediate nodes to start discarding delayed packets means that 
the packets are significantly delayed.  Service quality would suffer if the 
sender has to wait until the delay is bad enough before adapting its 
sending rate.  Feeding back delay adjustments before delay conditions get 
so bad would provide finer control over E2E delay and the service quality.

Regards,

-Nik

>>>>>http://www.ietf.org/internet-drafts/draft-hdesineni-avt-avpf- ccm- 
>>>>>pd-extn-00.txt
>>>>>

---

From: Nikolai Leung <[email-masked]>
Date: Fri, 17 Mar 2006 16:48:51 -0500

>Don't we have a "late packets" counter in RTCP-XR? That would do the

Hi David,

I assume you are referring to the 'discard rate' specified in RFC 3611.  If 
so, it has the following shortcomings for the scenario we are trying to 
address:

1.  The receiver must actually discard packets before it can report a 
problem back to the sender.  This means the delay would have to be long 
enough to cause service degradation (discarded packets) before the sender 
would start adapting its rate.  Also, if a receiver decided to adaptively 
delay its play out times to avoid discarding packets it would not be able 
to use this counter to tell the sender to adapt its rate (and improve 
transmission delay through a low bandwidth link condition).

2.  Since the loss rate is computed as a fraction of discarded rates since 
the beginning of reception it carries the history of all past discarded and 
not discarded packets.  So over time, this fraction becomes a less accurate 
estimate of the current packet arrival conditions.

For example, suppose the receiver has expected 10,000 packets since the 
start of the RTP session and has discarded 500 of them because of 
delays.  According to RFC 3611, the 'discard rate' is INT[256*500/10,000] = 
12.  Now if the receiver discarded 10 of the next 100 packets because of 
delays the resulting 'discard rate' would still be 12 according to the 
formula in RFC 3611.  So the sender can not adapt based on this 'discard 
rate' value since it would not detect any difference.

Regards,

-Nik

>>The PDAR message allows terminals to still perform de-jitter buffer/ play 
>>out time management based on packet arrivals.  But it also

---

From: Colin Perkins <[email-masked]>
Date: Sat, 18 Mar 2006 16:17:18 +0000

Nikolai,

If the existing statistics are insufficient, why not define  
additional statistics that can be reported? Provide information for  
the sender to make an appropriate decision on how to modify its  
transmission, but allow the sender to make that choice. This would be  
much more in keeping with the RTP philosophy than the current  
proposal, and would also ease operation in multicast and multiparty  
sessions.

Colin

On 17 Mar 2006, at 21:48, Nikolai Leung wrote:
> I assume you are referring to the 'discard rate' specified in RFC  
> 3611.  If so, it has the following shortcomings for the scenario we  
> are trying to address:
>
> 1.  The receiver must actually discard packets before it can report  
> a problem back to the sender.  This means the delay would have to  
> be long enough to cause service degradation (discarded packets)  
> before the sender would start adapting its rate.  Also, if a  
> receiver decided to adaptively delay its play out times to avoid  
> discarding packets it would not be able to use this counter to tell  
> the sender to adapt its rate (and improve transmission delay  
> through a low bandwidth link condition).
>
> 2.  Since the loss rate is computed as a fraction of discarded  
> rates since the beginning of reception it carries the history of  
> all past discarded and not discarded packets.  So over time, this  
> fraction becomes a less accurate estimate of the current packet  
> arrival conditions.
>
> For example, suppose the receiver has expected 10,000 packets since  
> the start of the RTP session and has discarded 500 of them because  
> of delays.  According to RFC 3611, the 'discard rate' is INT 
> [256*500/10,000] = 12.  Now if the receiver discarded 10 of the  
> next 100 packets because of delays the resulting 'discard rate'  
> would still be 12 according to the formula in RFC 3611.  So the  
> sender can not adapt based on this 'discard rate' value since it  
> would not detect any difference.
>
> Regards,
>
> -Nik
>
>>> The PDAR message allows terminals to still perform de-jitter  
>>> buffer/ play out time management based on packet arrivals.  But  
>>> it also

---

From: Nikolai Leung <[email-masked]>
Date: Sun, 19 Mar 2006 10:11:18 -0500

Hi Magnus,

Thanks for the suggestions and comments.

I agree with your point that changes in delay that are not caused by 
congestion will also affect this delay statistic (as a measurement of 
congestion).  I would like to understand the severity of such 
non-congestion-related delay changes.  The congestion-related delays from 
HSDPA/HRPD links can range from tens of milliseconds to a second or 
more.  And variations can happen as frequently as every 2-3s.

Are non-congestion related delays as significant and frequent?  And what 
would cause them?

Regarding RFC 3550 and 3611, the receiver could report the arrival times of 
individual packets in the Packet Receipt Times Block.  This would allow the 
sender to determine changes in the transmission delay between 
packets.  However one concern I have is that this requires a lot of 
statistics to be reported back to the sender (arrival time for each packet) 
vs. sending a single average adjust value.  This also does not allow the 
sender to account for any play out time adjustments made by the receiver 
(e.g., receiver adaptively decides to delay its play out times because of 
delayed packets).

Regards,

-Nik

At 05:26 AM 3/15/2006, Magnus Westerlund wrote:
>So your proposed mechanism is in fact a receiver to sender notification on 
>the receiver perceived changes in the delay between the sender and 
>cause delay changes and jitter. The delay consists of so many components. 
>If they could be seen only as static delay and variable congestion 
>dependent delay then it would be an excellent indication of congestion. 
>However it is the part that is non-congestion related delay changes or 
>jitter. There is also the issue of delayed transmission that an RTP 
>receiver totally lacks information about. Due to the lack of transmission 
>timestamping of RTP packets, a receiver is unable to determine anything 
>for certain about the transport delay between the sender and the receiver.
>
>arrival jitter that exist in the RTP/RTCP framework. The TTL measurements 
>in RTCP (RFC 3550) and the extended reports available in RFC 3611. These 
>mechanism is intended to allow the sender to determine the round-trip time 
>and compare the actual arrival times to its transmission times, that way 
>it can determine changes in the transmission delay between packets.
>
>Cheers
>
>Magnus
>
>Nikolai Leung wrote:
>>Hi Magnus,
>>delay of over 600ms.  The number of users seeing longer delays gets worse 
>>as the loading in the cells increases (i.e., going from 8 to 12 users/cell).
>>(closer to the base station) or lightly loaded cells, it still suffers 
>>from the problem that as the user moves further away from the base 
>>station or more users enter the cell the user will experience 
>>"Request."  It does not request that packets be sent earlier by the 
>>and/or congestion from cell loading too heavy to support the current rate 
>>it is transmitting at.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Mar 2006 11:36:32 -0500

Nikolai Leung <[email-masked]> writes:
>non-congestion-related delay changes.

The answer is ... it depends.  Any answer is valid only for a subset of
uses/users of RTP.  And the answer changes from year to year.

>The congestion-related delays from
>HSDPA/HRPD links can range from tens of milliseconds to a second or more.
>And variations can happen as frequently as every 2-3s.

Ouch.

>Are non-congestion related delays as significant and frequent?  And what

Significant and frequent?  It depends.

Common causes: 
- Temporary (sub-second) router queuing due to router load or output link
  congestion.  Eventually this leads to packet loss of one form or another
  if it continues.
- Route changes due to traffic leveling, link loss, congestion avoidance,
  or route flapping.
- Changes in shared broadband uplink utilization (such as cable modems)
  by competing sources.
- Rate-limiting by provider due to other traffic from the same source
  (uplink caps on outbound link when other traffic from the same
  home/business increases - specific case of the first item)
- Link loss/bandwidth changes (like in the radio links you mention)
(Did I miss any?)

-- 
Randell Jesup
[email-masked]