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

From: Tom Taylor <[email-masked]>
Date: Thu, 03 Jun 2010 10:03:14 -0400

This is to remind you of the agreements we reached in the Anaheim meeting:

1. No fallback solution is to be recommended, and in particular, use of an 
unknown payload type is not to be recommended. The fact that the use of an 
unknown payload type is a violation of RFC 3264 is to be documented.

2. No one commented on the usefulness of the a=rtp-keepalive attribute. I 
suggest that if no one speaks to its favour in the next couple of days it should 
be dropped.

3. Perhaps a sentence should be added in the introduction making the point that 
since RTP/RTCP multiplexing is the recommended solution, the protection of RTCP 
connectivity is automatically covered by the recommendations of this document 
and need not be dealt with separately.

4. Section 6.1 and the sentence preceding that sub-section are to be removed.

5. We need more text on timer values, taking into account the RTCP timing is a 
key feature of the recommended solution.

6. Add a few words to allow the uninitiated to understand what is meant by an 
"ICE agent".

7. Update the bullet on comfort noise to talk about muting instead of silence 
suppression.

8. Remove REQ-9.

9. Send a text proposal for your Comment 12.

[email-masked] wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>
Date: Fri, 4 Jun 2010 15:03:44 +0300

Hi,

I did not follow the discussions about the draft. And I am a mere coding
guy, so may not have the proper insights. So my comments may be
absolutely inappropriate. Sorry for that.

It seems to me that draft-ietf-avt-app-rtp-keepalive and section 10 of
RFC5245 (ICE) are both discussing keepalive mechanisms, but they are not
harmonized, at all. RFC5245 suggests several keepalive options, an ICE
mechanism and fallback ones.

Options in RFC5245:

1) STUN Binding Indication (RFC5389)

2) Using a negotiated RTP No-Op payload (draft-ietf-avt-rtp-no-op).

3) Using a negotiated comfort noise.

4) Send incorrect RTP packets "that would cause them to be discarded by
the peer". Section K.5.2.1 of 3GPP TS 24.229 v9.3.1 explicitly states
that "UE shall send an empty (no payload) RTP packet with a payload type
of 20 as a keepalive". That is fine, as according to section 6 of
RFC3551 PT 20 is unassigned.

Findings:

a) RTCP multiplexing is a fine option. I agree that this should be the
most RECOMMENDED one.

b) RTCP multiplexing is unquestionably a much better technical approach
than PT 20 in most cases. But I do not find it reasonable to drop PT 20
option. It is so charmingly simple that even 3GPP guys fell in love with
it. :-)

c) According to the Abstract of the draft "This document is not
applicable to Interactive Connectivity Establishment (ICE) agents." Then
why to have section 4.4. "STUN Indication Packet"? Is not there a
contradiction?

d) Section 4.1 sounds strange. I guess it is not possible to transport
zero-byte packet over UDP or TCP. Receiving zero bytes (using POSIX
recv/recvmsg/recvfrom functions) may be interpreted as closing of
connection. So I would avoid that as far as possible. I do not think
it's worth even mentioning that in the draft.

BR,
Som

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Tom Taylor
Sent: Thursday, June 03, 2010 16:03
To: [email-masked]
Cc: 'DRAGE, Keith (Keith)'; IETF AVT WG
Subject: Re: [AVT] IESG feedback on draft-ietf-avt-app-rtp-keepalive-07

This is to remind you of the agreements we reached in the Anaheim
meeting:

1. No fallback solution is to be recommended, and in particular, use of
an unknown payload type is not to be recommended. The fact that the use
of an unknown payload type is a violation of RFC 3264 is to be
documented.

2. No one commented on the usefulness of the a=rtp-keepalive attribute.
I suggest that if no one speaks to its favour in the next couple of days
it should be dropped.

3. Perhaps a sentence should be added in the introduction making the
point that since RTP/RTCP multiplexing is the recommended solution, the
protection of RTCP connectivity is automatically covered by the
recommendations of this document and need not be dealt with separately.

4. Section 6.1 and the sentence preceding that sub-section are to be
removed.

5. We need more text on timer values, taking into account the RTCP
timing is a key feature of the recommended solution.

6. Add a few words to allow the uninitiated to understand what is meant
by an "ICE agent".

7. Update the bullet on comfort noise to talk about muting instead of
silence suppression.

8. Remove REQ-9.

[email-masked] wrote:
> 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.
> 

> 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:
> document's current approach of RECOMMENDING falling back to Section 
> 4.6 (sending RTP with an unknown payload type) is a mistake.
> 
> Proposal: 
> mecanism is NOT RECOMMENDED. Anyhow keep other mechanims in the draft 
> to document discussion about them.
> 
> 
> that it was needed. I don't think the IETF needs to change its 
> position on that point.

> 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: 

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

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

> of uni- directional RTP flows. The failure to mention RTSP and 
> streaming seems strange.
> 
> Proposal: 

> 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?
> 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 
> offer/answer", but I realise this ends-up with something too similar 
> to the other con.
> 
> 
> Cheers,
> Xavier
> 
> 
> 
> 
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 18 Jun 2010 16:42:31 +0200

Hi, 

We have just submitted a new version of the rtp keepalive draft addressing all the points agreed during the last IETF meeting.

There is stil one remaining work according to last meeting: to specify, for each transport protocol, the duration between two keepalive messages. We will send a mail to the Behave WG to ask the recommended values.

Cheers,
Xavier and Aurelien

-----Message d'origine-----
De : Tom Taylor [mailto:[email-masked]] 
Envoyé : jeudi 3 juin 2010 16:03
À : MARJOU Xavier RD-CORE-LAN
Cc : Roni Even; 'DRAGE, Keith (Keith)'; IETF AVT WG
Objet : Re: [AVT] IESG feedback on draft-ietf-avt-app-rtp-keepalive-07

1. No fallback solution is to be recommended, and in particular, use of an unknown payload type is not to be recommended. The fact that the use of an unknown payload type is a violation of RFC 3264 is to be documented.
[Xavier] done

2. No one commented on the usefulness of the a=rtp-keepalive attribute. I suggest that if no one speaks to its favour in the next couple of days it should be dropped.
[Xavier] done

3. Perhaps a sentence should be added in the introduction making the point that since RTP/RTCP multiplexing is the recommended solution, the protection of RTCP connectivity is automatically covered by the recommendations of this document and need not be dealt with separately.
[Xavier] ok, added as a REQ

[Xavier] done

5. We need more text on timer values, taking into account the RTCP timing is a key feature of the recommended solution.
[Xavier] I will send a mail to behave to ask feedback on it

6. Add a few words to allow the uninitiated to understand what is meant by an "ICE agent".
[Xavier] done

7. Update the bullet on comfort noise to talk about muting instead of silence suppression.
[Xavier] done (actually bullet is simply removed because muting was described in previous bullet (on hold)

8. Remove REQ-9 "More than one mechanism MAY exist"
[Xavier] done

9. Send a text proposal for your Comment 12.
[xavier] not done, because no new text proposal was finally needed

[email-masked] wrote:
> be used if another SSRC than the ones used to transport actual media are used.
> 
> mention any codec that would produce CN with longer interval than 1 second?
> 
> Proposal:

---

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jun 2010 16:11:54 -0500

I've updated my discuss clearing the point this revision addresses and putting in a token to track the resolution of the [TODO]s called out below.

RjS