Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
draft-ietf-avt-app-rtp-keepalive-10

[Ballot discuss]
Updated for -08-

1. RTCP is an integral part of RTP. This document can't rule
RTCP out of scope. It needs to be covered.

[Ballot comment]
Comment (2010-02-17)

Section 1, first bullet:

RTSP and streaming should be mentioned, since these are important uses of unidirectional RTP flows.

Section 4:
Please discuss how the potential solutions meet the requirements.

section 4.6 - the English in the new text needs work.
OLD:
The SSRC is the same than one one of the media for which keepalive is  sent.
NEW:
The SSRC is the same as for the media for which keepalive is  sent.

[Ballot discuss]
Updated for -08-

1. RTCP is an integral part of RTP. This document can't rule
RTCP out of scope. It needs to be covered.

2. Section 7: The [TODO] markers in the text must be resolved by defining appropriate values for the different protocols.

[Ballot comment]
Comment (2010-02-17)

Section 1, first bullet:

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.

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

Section 3, REQ-9:

This is not a requirement, it is a statement about the world.

Section 4:
The subsections on the potential solutions does not discuss how they
meet the requirements.

[Ballot discuss]
I think there is good value in publishing some of this content. However, some
things should be addressed prior to the documents approval.

1. 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. To me this document can't rule
RTCP out of scope. It needs to be covered.

And normally it isn't difficult as regular RTCP reports maximum periodic
interval is shorter than the the bindings. However, there are some important
configuration considerations that needs to be covered. It will also require
symmetric usage of RTCP between transport peers.

2. Section 4.6:

This solution does not discuss which SSRC should be used. That has significant
impact if the solution is possible to use or not. There are a number of RTP
payload formats that does not handle gaps in RTP sequence number well. T.140
text is one of these. Thus this solution is only plausible in that case to use a
different SSRC.

6. Section 7: I 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.

[Ballot discuss]
The document has a couple of [TODO]s still listed. The authors indicated on the AVT list that they would be coordinating with the BEHAVE working group to clear those open issues.

[Ballot comment]
Comment (2010-02-17)

Section 1, first bullet:

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.

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

Section 3, REQ-9:

This is not a requirement, it is a statement about the world.

Section 4:
The subsections on the potential solutions does not discuss how they
meet the requirements.

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.

I think my comments and discusses around 4.6 supports Robert Sparks discuss that
the solution does not come without issues.

[Ballot discuss]
I think there is good value in publishing some of this content. However, some
things should be addressed prior to the documents approval.

1. 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. To me this document can't rule
RTCP out of scope. It needs to be covered.

And normally it isn't difficult as regular RTCP reports maximum periodic
interval is shorter than the the bindings. However, there are some important
configuration considerations that needs to be covered. It will also require
symmetric usage of RTCP between transport peers.

2. Section 4.6:

This solution does not discuss which SSRC should be used. That has significant
impact if the solution is possible to use or not. There are a number of RTP
payload formats that does not handle gaps in RTP sequence number well. T.140
text is one of these. Thus this solution is only plausible in that case to use a
different SSRC.

This in its turn has negative impact on one thing. There is implementations that
are badly implemented in regards to handling multiple SSRC's. They may kill of
the state for the media sending SSRC. I do agree that they are not standards
compliant.

3. Section 4:
In general I am missing a discussion on which solutions results in
RTCP reporting on the keep-alive packets. At least 4.2 and 4.6 can result in
reporting on the keep-alive packets. In 4.6 it is not 100% clear what should
happen so that needs to be made clear to avoid issues.

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

I do agree with the second paragraph that for T.140 there is little need to use
anything else than the idle mechanism.

5. section 5:

What is the interpretation of the a=rtp-keepalive attribute in multicast
sessions?

6. Section 7: I 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.

[Ballot comment]
Section 1, first bullet:

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.

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

Section 3, REQ-9:

This is not a requirement, it is a statement about the world.

Section 4:
The subsections on the potential solutions does not discuss how they meet the requirements.

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.

I think my comments and discusses around 4.6 supports Robert Sparks discuss that the solution does not come without issues.

[Ballot discuss]
I think there is good value in publishing some of this content. However, some things should be addressed prior to the documents approval.

1. 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. To me this document can't rule RTCP out of scope. It needs to be covered.

And normally it isn't difficult as regular RTCP reports maximum periodic interval is shorter than the the bindings. However, there are some important configuration considerations that needs to be covered. It will also require symmetric usage of RTCP between transport peers.

2. Section 4.6:

This solution does not discuss which SSRC should be used. That has significant impact if the solution is possible to use or not. There are a number of RTP payload formats that does not handle gaps in RTP sequence number well. T.140 text is one of these. Thus this solution is only plausible in that case to use a different SSRC.

This in its turn has negative impact on one thing. There is implementations that are badly implemented in regards to handling multiple SSRC's. They may kill of the state for the media sending SSRC. I do agree that they are not standards compliant.

3. Section 4:
In general I am missing a discussion on which solutions results in RTCP reporting on the keep-alive packets. At least 4.2 and 4.6 can result in reporting on the keep-alive packets. In 4.6 it is not 100% clear what should happen so that needs to be made clear to avoid issues.

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

I do agree with the second paragraph that for T.140 there is little need to use anything else than the idle mechanism.

5. section 5:

What is the interpretation of the a=rtp-keepalive attribute in multicast sessions?

6. Section 7: I 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.

[Ballot discuss]
(1) Given that it is declarative (and not subject to negotiation) I do not understand the utility
of the a=rtp-keepalive SDP attribute.  Since the agent intends to use this solution if the
a=rtcp-mux is not recognized whether the rtp-keepalive is recognized or not, it doesn't seem
to add much value.  Are you expecting middleboxes to process this value?  If no entity is
going to act on this information, why send it?

(2) [Similar to Robert's discuss]  I agree that multiplexing RTCP and RTP packets is an
excellent solution.  I also think that incorrect version numbers (as specified in 4.5) would be
a terrible waste, given the limited number of possibilities.  The remaining solutions all seem
to have merit for some scenarios, as well as significant drawbacks.  Perhaps it would be better
to recognize multiplexing RTCP and RTP as the recommended solution, forbid the incorrect
version number solution, and let applications pick their poison when a=rtcp-mux does not
appear in the answer.

(3) While a peer is required by RFC 3530 to "ignore packets with payload types it does not
understand", that does not preclude examination by the peer in an attempt to determine if
it is under attack.  Since falling back to the alternative indicates the peer is not aware of this
specification, the Cons for section 4.6 should note that the peer may consider the
keepalive traffic a DOS attack and terminate the connection.

[Ballot discuss]
(1) Given that it is declarative (and not subject to negotiation) I do not understand the utility
of the a=rtp-keepalive SDP attribute.  Since the agent intends to use this solution if the
a=rtcp-mux is not recognized whether the rtp-keepalive is recognized or not, it doesn't seem
to add much value.  Are you expecting middleboxes to process this value?  If no entity is
going to act on this information, why send it?

(2) [Similar to Robert's discuss]  I agree that multiplexing RTCP and RTP packets is an
excellent solution.  I also think that incorrect version numbers (as specified in 4.5) would be
a terrible waste, given the limited number of possibilities.  The remaining solutions all seem
to have merit for some scenarios, as well as significant drawbacks.  Perhaps it would be better
to recognize multiplexing RTCP and RTP as the recommended solution, forbid the incorrect
version number solution, and let applications pick their poison when a=rtcp-mux does not
appear in the answer.

(3) While a peer is required by RFC 3530 to "ignore packets with payload types it does not
understand", that does not preclude examination by the peer in an attempt to determine if
it is under attack.  Since falling back to the alternative indicates the peer is not aware of this
specification, the Cons for section 4.6 should note that the peer may consider the
keepalive traffic a DOS attack and terminate the connection.

[Ballot discuss]
I am happy to see this discussion of ways that have been tried in the past to keep NAT bindings alive published. I support the conclusion that multiplexing RTCP and RTP is the RECOMMENDED solution and that the other mechanisms are NOT RECOMMENDED. However, I think the document's current approach of making falling back to sending RTP with an unknown payload type RECOMMENDED is a mistake.

The document argues that this "always works". That is inconsistent with what I have observed in the field. We lived through a period where simple un-negotiated comfort-noise packets were causing unintended malfunction in several kinds of endpoints. It is highly likely that implementations
seeing a null payload with an unsolicited type are going to do something very unexpected.

In general, recommending that elements violate part of a specification because some other part of the specification says to ignore that violation is very dangerous and will lead to long term interoperability problems. The robustness principle being taken advantage of here has two parts - Be conservative in what you send ("Don't send things you haven't been told are ok to send") and Be liberal in what you receive ("Don't break if the other guy sends you the wrong thing") only works when most of the elements do both things. Asking a large part of the system to ignore half of that equation removes the robustness.

The same argument this document is making to say it's ok to send these will eventually be used by stack or middlebox implementors to drop these packets before they get to where they've possibly done any good.

I think this document should keep the discussion of these alternate techniques, and even point out that of the alternatives other than multiplexing RTP/RTCP, sending unsolicited payload types breaks fewer things. But putting that forth as a Proposed Standard way to behave is not the right thing to do.

[Ballot comment]
Title
s/maintaining/keeping/


Need to expand acronyms the first time they show up in the document body
For example, ICE


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.

[Note]: 'This still needs to be put on an IESG call. Started to for Oct 22, 2009 call but then took if off that call to give time to resolve some issues.' added by Cullen Jennings

[Ballot comment]
Section 1., paragraph 15:
>    Note that if a given media uses a codec that already integrates a
>    keepalive mechanism, no additional keepalive mechanism is required at
>    the RTP level.

  And since redundant keepalives waste bandwidth and energy, do we want
  to say they're NOT RECOMMENDED?

[Ballot discuss]
Good document. I'd like to bring up one quick issue:

Section 7., paragraph 1:
>    An application supporting this specification MUST transmit either
>    keepalive packets or media packets at least once every Tr seconds
>    during the whole duration of the media session.  Tr SHOULD be
>    configurable, and otherwise MUST default to 15 seconds.

  DISCUSS: Please see Section 3.5 of RFC5405 and check if you want to
  bring your recommendation in line with what we've written there
  (SHOULD NOT send more frequently than every 15 sec, SHOULD investigate
  if other mechanisms are available, etc.) You might also want to quote
  or refer to some of the other content of that section here, since
  this text talks more generally about when keepalives are appropriate.

IANA comments:

Upon approval of this document, IANA will make the following assignment
in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
rtp-keepalive [RFC-avt-app-rtp-keepalive-05]

We understand the above to be the only IANA Action for this document.

This is just largely defining  a way for the UA to deal with keep alives - I'd like to change the track from BCP to Proposed Standard. Does this cause any problems?

When using RTCP mux, I'd like a little more information about what RTCP you send. Particularly in the case of a one way media stream where the sender is behind the NAT.

Thought I know we typically don't use static payload types, this seems like an ideal one to use a static payload type for. This could allow diagnostic and logging tools that did not see the SDP to still be able to understand what was going on. Thoughts?

Does a device that does not support the fallback solution but will do the RTCP-mux include the keep-alive attribute?

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Taylor is Document Shepherd. I have read this version of the
document and believe it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been well reviewed, by participants in the AVT,
BEHAVE, and MMUSIC Working Groups. It began in 2007 as a BEHAVE work
proposal with a broader scope, but was eventually focussed on
RTP keepalive in the absence of ICE support.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concern.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid WG consensus. As evidenced by the Acknowledgements
section, a number of people provided comments that helped the
document take shape along the way.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

ID nits is confused about the presence of the RFC 2119
boilerplate text, but it is there as section 2. All OK
otherwise.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All OK.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

All OK. The proposed rtp-keepalive SDP parameter drew no
comments from MMUSIC.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document lists the different mechanisms that enable applications
using Real-time Transport Protocol (RTP) to maintain their RTP
Network Address Translator (NAT) mappings alive. It also makes a
recommendation for a preferred mechanism. This document is not
applicable to Interactive Connectivity Establishment (ICE) agents.

Working Group Summary
This document began in 2006 as a proposed BEHAVE work item with
broader scope. The scope was refined after discussion between
BEHAVE, MMUSIC, and AVT Working Groups to that indicated above.
The rtp-keepalive SDP parameter was added by direction of the
AVT Chair when no comments were received either for or against
that proposal.

Document Quality
This document was shaped by comments from a number of contributors,
as listed in the Acknoledgements section. As a general application
guide, it is expected to have broad implementation.

(end)