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

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 5 Oct 2005 09:37:14 +0200

Hello Flemming,

noting that "no-op" payloads aren't too popular within AVT 
yet, let me first express my support for the rtp no op 
draft. I also like the idea of using RTCP functionalities, 
which were added in the latest version of your document. 

The draft demands the RTCP report to be "early". I don't 
know whether the no-op draft itself is planned to get more 
specific, but some document should define what's meant by 
an early RTCP report. Some questions come to my mind:

- the first received packet triggers RTCP. When does RTCP stop 
  and build the early report?
- 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?
- should the number of packets or the measurement interval of 
  the receiver or both be specified?
- should there be a timer at the source of the no-op packets 
  to determine until when the early RTCP report should have 
  been received? Hypothetically, all no-op packets may get 
  dropped by the network and no RTCP report may be created 
  at all. The application should be able to cope with such 
  a situation.

I'm not on the avt-list and I'd appreciate responses of you 
or the receivers I addressed directly being copied to me.

Regards,

Rüdiger

Rüdiger Geib

T-Systems International GmbH
Senior Expert
Systems Integration 
Technologiezentrum
Engineering Networks, Products & Services
Packet based Carrier Transport Networks
Deutsche-Telekom-Allee 7, D-64295 Darmstadt
Fon: +49 6151 937-2138
http://www.t-systems.com

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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Oct 2005 09:40:10 -0400

Geib, Ruediger wrote:

>draft.
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.)
2. A mechanism to ask for an early RTCP report, which in turn provides 
RTP reception quality statistics.

Which part(s) of the above do you (and other's) see as valuable ?

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 ?

> I also like the idea of using RTCP functionalities, 
>an early RTCP report.
The various RTP profiles define when you normally generate an RTCP 
report. An early RTCP report is simply generated before it otherwise 
would have been based on the particular profile you are using. One of 
the problems we are struggling with right now

> Some questions come to my mind:
>
Not the first packet - only when you receive a packet with the "Request 
Early RTCP Report" bit set to 1.

>  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).

>  the receiver or both be specified?
No. Also note, that the receiver simply acts based on the senders 
request for an early RTCP report.

>  at all. The application should be able to cope with such 
Right - again, this depends on what you are using the RTP No-Op for. The 
payload format defintion itself should not get into this, however 
particular use cases may want to.

-- Flemming