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

[<[e-mail]>]

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:[e-mail]] 
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

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

4. Section 6.1 and the sentence preceding that sub-section are to be removed.
[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


[e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt