Subject: [AVT] IESG feedback on draft-ietf-avt-app-rtp-keepalive-07

From: <[email-masked]>
Date: Wed, 17 Mar 2010 11:03:14 +0100

Here is some feedback from the IESG on
draft-ietf-avt-app-rtp-keepalive-07.

The IESG globally think that there is value in publishing a document for
much of the content of the current draft. However many discuss and
comments were sent-back. Here is the complete list, as well as proposals
for a way-forward.

1- There are some concerns that the currently recommended fallback
method of Section 4.6 has more drawbacks than currently stated: First,
RFC3550 does not preclude examination of received packets by the peer in
an attempt to determine if it is under attack. Secondly: the statement
"RTP Packet with Unknown Payload Type" of RFC3550 is not always observed
in real life. Thirdly: the solution does not discuss which SSRC should
be used.

Proposal:
- Add the cons raised by the IESG for Section 4.6.

2- There is some support on the conclusion that multiplexing RTCP and
RTP is the RECOMMENDED. However, there is some feedback that the
document's current approach of RECOMMENDING falling back to Section 4.6
(sending RTP with an unknown payload type) is a mistake.

Proposal: 
- Keep previous consensus of WG (what is described in 07 draft).
- Or RECOMMEND "multiplexing RTCP and RTP" and state that any other
mecanism is NOT RECOMMENDED. Anyhow keep other mechanims in the draft to
document discussion about them.

3- There is also some concern that the a=rtp-keepalive declarative is
not useful. As a reminder, there was a clear consensus from the group
that it was needed. I don't think the IETF needs to change its position
on that point.
(http://www.ietf.org/mail-archive/web/mmusic/current/msg07135.html). A
derived question is also the following: "what is the interpretation of
a=rtp-keepalive attribute in multicast session"

Proposal: 
- Keep previous consensus of WG (what is described in 07 draft).
- Or decide it is not needed if the fallback solution is not used. 

4- RTCP is an integral part of RTP. There are a number of mechanism that
doesn't work unless also the RTCP flows are kept alive. This document
can't rule RTCP out of scope. It needs to be covered. 

Proposal: 
- Keep previous consensus of WG (what is described in 07 draft).
- Or ask the WG if we want to rescope the document to discuss RTCP as
well. If yes, additional editing help is needed.

5- Section 4 needs to discuss which solutions result in RTCP reporting
on the keepalive packets.

Proposal: 
- Depends on the choice made for point 4.

6- Section 6.1, first paragraph: This section is in error. T.140
requires that for the SSRC(s) one is using that the sequence number
space is continous. If one switches to another media format, and do not
attempt to use them intermixed it can work. Thus, method 4.6 can be used
if another SSRC than the ones used to transport actual media are used. 

Proposal: Remove first paragraph.

7- Section 7: Agree with minimal value for Tr of 15 seconds. It makes
sense when sent over UDP. However, a significant larger value, like 5 to
15 min makes more sense for TCP. This is an area where it is difficult
to provide good recommendations without considering the underlying
transport protocol.

Proposal: 
- Keep previous consensus of WG (what is described in 07 draft).
- Or modify with the following: in section 7, after "The minimum
RECOMMENDED Tr value is 15 seconds, and Tr SHOULD be configurable to
larger values." add a sentence like "Tr is bound to the underlying
transport protocol".

8- Introduction: The "this does not apply to ICE agents" is a bit terse
and cryptic. If the reader might not know what an ICE agent is, you
should probably describe it. You might also reasonably explain *why*
this document does not apply to ICE agents.

Proposal: 
- Keep previous consensus of WG (what is described in 07 draft).
- Or add a sentence like "ICE is the protocol for solving the overall
Network Address Translator (NAT) traversal. This document is limited to
discussing how to realise the specific task of a keepalive mechanism for
agent that would not use the ICE protocol.

9- I would say that streaming applications is one of the biggest usage
of uni- directional RTP flows. The failure to mention RTSP and streaming
seems strange.

Proposal: 
- Do nothing about this comment unless a concrete example of keepalive
problem in an RTSP problem can be provided. (To my knowledge, the
problem mentionned above would be rather be related to opening a NAT
pinhole rather that maintaining a NAT pinhole open, which is the current
topic of the draft).

10- Section 1, bullet 3: It appears inaccurate that comfort noise would
be sent too seldom that a NAT binding would timeout. Can you mention any
codec that would produce CN with longer interval than 1 second?

Proposal: 
- If someone can mention such a codec, let's mention it. Otherwise
remove bullet 3.

11- REQ-9: This is not a requirement, it is a statement about the world.

Proposal: 
- Remove REQ-9.

12 - Section 4.3: How can it be a con to require SDP signaling when you
state in REQ-8 that is desirable. In fact only REQ-7 isn't supported by
this solution which is a pretty good Pro list.

Proposal: 
- Replace "advertise" by "described" in REQ-8, and remove the 4.3 con on
SDP. I was about to propose to reword this 4.3 con "Multiplexing RTP and
RTCP must be signalled in SDP offer/answer" is something like
""Multiplexing RTP and RTCP must be negotiated when used in SDP
offer/answer", but I realise this ends-up with something too similar to
the other con. 

Cheers,
Xavier