Subject: RE: [AVT] Timing of early RTCP report for no-op payload

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 13 Oct 2005 09:39:32 +0200

Hello Flemming,

|Seems like a good opportunity to discuss a few things. RTP 
|No-Op really provides two things:

|1. A "dummy" RTP packet that can keep NAT bindings and 
|Firewall pinholes alive, generate synthetic load which 
|in turn updates the reception statistics on the other side. 
|All of this is done without actually affecting the media 
|stream itself (i.e. there is no impact on the media 
|codec used otherwise, e.g. in terms of comfort noise, silence 
|suppression, etc.)

I'm not a NAT/FW expert and I couldn't argue for or against 
this proposal. If it helps to simplify NAT tarversal issues, 
I certainly like it.
I completely forgot this No-op application when I formulated 
my statements in my original mail, which you pointed out by 
your calm and friendly answering statements.

|2. A mechanism to ask for an early RTCP report, which in turn provides 
|RTP reception quality statistics.

I'm looking for this type of application.

|In case both parts are seen as valuable, should they be kept together 
|(as in the current draft), or should they be split in two ?

My view:

The basic No-op packets and mechanisms should be identical, if possible. 
Integration into SIP and attributes referring to the No-op NAT/FW 
features or the RTP reception statistic feature within SDP may benefit 
from a differentiation. That would mean either to indicate no-op and 
what kind of no-op or directly the kind of no-op operation supported 
by an implementation. 

[snip]

Below I'm asking for a rather detailed no-op performance measurement 
specification. The benefit of not having one is that each sender 
can follow its own measurement design and result interpretation. The 
advantage of specifying the measurement flow would be, that a remote 
receiver could interpret the results by himself (instead of or in 
addition to crating a RTCP reprt), which could speed up session set 
up (the receiver doesn't have to wait one RTT after having 
created the RTCP report to learn about the performance 
interpretation). 
But I also think that different solution options may be tried and 
compared. No-op would be a reasonable step ahead if it allows for 
transfer of No-op RTP payload - details like the ones I've suggested 
may follow later.  

Regards,

Rüdiger

|>- for how long should a source transmit no-op packets? Should 
|>  the number of no-op packets or the sending interval of 
|>  no-op packets or both be specified?
|>  
|>
|No. First of all, the rate and number depends on the usage (e.g. 
|keepalive, load generation, or some kind of quality assesment). 
|Secondly, different networks may have different preferences 
|depending on usage (e.g. rate and number of packets to use 
|for initial network quality assesment).
|
|>- should the number of packets or the measurement interval of 
|>  the receiver or both be specified?
|>  
|>
|No. Also note, that the receiver simply acts based on the senders 
|request for an early RTCP report.

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