Subject: Re: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Jul 2007 15:27:10 +0100

David,

Thanks for the review - some comments inline.

On 16 Jul 2007, at 22:35, [email-masked] wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call
> comments you may receive.
>
>
> Document: draft-ietf-avt-rtp-and-rtcp-mux-05.txt
> Reviewer: David Black
> Review Date: 16 July 2007
> IETF LC End Date: 17 July 2007
>
> Summary:
> This draft is on the right track, but has open issues,
> described in the review.
>
> Comments:
>
> The draft is generally in good shape, although one needs to
> be an RTP expert to understand all the details.
>
> The only "open issue" is the missing instructions to IANA
> for RTCP packet type registration - from a technical standpoint,
> this is a nit, but getting it right is of sufficient importance
> to avoidance of future restrictions RTP/RTCP multiplexing that
> I've flagged it as an open issue.
>
> Everything else in this review is an editorial comment, although
> the absence of the explanation of the mechanics of the RTP/RTCP
> conflicts makes that section of the draft difficult to read.
>
> Section 1 talks about NAT (Network Address Translation) as a
> motivation, but the real motivation appears to be NAPT (Network
> Address Port Translation).  This ought to be discussed, and I
> strongly suggest an Informative reference to RFC 3022.  The
> term "NAT pinhole" also needs to be explained here to connect
> the problems caused by two UDP ports to NAPT usage, and it
> may be useful to mention firewall pinholes as a related issue.

We can change "Network Address Translation (NAT)" to "Network Address  
Port Translation (NAPT)" in the Introduction, and add a reference to  
RFC 3022, sure. Sloppy terminology on my part.

Would changing "since opening multiple NAT pinholes can be costly" to  
"since maintaining multiple NAT bindings can be costly" address your  
other concern?

> Section 4 should explain the mechanics of the RTP/RTCP conflict:
> - The RTCP PT is bits 8-15.
> - The RTP PT is bits 9-15.
> - RTP uses bit 8 in that word for a M (Marker) bit that
> 	may be on or off.
> The latter item is the cause for needing to check for whether the
> RTCP PT conflicts with either the RTP PT or the RTP PT + 128.

The draft hints at this already in section 4:

    This demultiplexing method works because the RTP payload type and
    RTCP packet type occupy the same position within the packet.

If you think more is needed, please suggest wording, and I'll add it.

> The last 2 paragraphs in Section 4 before the final Note in that
> section need attention:
> - The paragraph on registration of new RTCP packet types needs to
> 	instruct IANA on what rules to enforce.  The use of "SHOULD"
> 	in the current text is not sufficient, instead this needs to
> 	be restated as instructions to IANA on how to assign RTCP
> 	packet types and noted in the IANA considerations section.

Makes sense. I suggest adding something like the following to the  
IANA considerations:

    The rules for assignment of RTP RTCP Control Packet Types in the RTP
    Parameters registry are updated as follows.  When assigning RTP RTCP
    Control Packet types, IANA is requested to assign unused values from
    the range 200-254 where possible.  If that range is fully occupied,
    values from the range 194-199 may be used, and then values from the
    range 1-191. This improves header validity checking of RTCP packets
    compared to RTP packets or other unrelated packets. The values 0 and
    255 are avoided for improved validity checking relative to random
    packets since all-zeros and all-ones are common values.

> - In this text in the second paragraph:
>
>    Given these constraints, it is RECOMMENDED to follow the guidelines
>    in the RTP/AVP profile [7] for the choice of RTP payload type  
> values,
>
> 	Insert the word "dynamic" between "the choice of" and "RTP
> 	payload type values" for clarity.

The guidelines in the RTP/AVP profile apply to both static and  
dynamic RTP payload types, so inserting "dynamic" here would be  
incorrect.

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Jul 2007 16:58:44 +0100

On 17 Jul 2007, at 16:33, [email-masked] wrote:
> idnits 2.04.12 found a couple of reference nits:
>
>    Checking references for intended status: Proposed Standard
>
> ---------------------------------------------------------------------- 
> --
>
>      (See RFC 3967 for information about using normative references to
>      lower-maturity documents in RFCs)
>   ** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted  
> by RFC
> 4587)

This is intentional, and noted in the PROTO write-up in the tracker,  
since the aim is to reference the FIR and NACK packets defined in RFC  
2032, then removed when the H.261 payload format was updated.

>   -- Possible downref: Normative reference to a draft: ref. '6'  (No
> intended
>      status found in state file of draft-ietf-avt-rtcpssm)

The draft-ietf-avt-rtcpssm-13.txt draft is intended for standards  
track, so this is not an issue.

>   == Outdated reference: A later version (-17) exists of
>      draft-ietf-mmusic-ice-15

ICE -16 and -17 were both submitted after this draft. The reference  
was current on submission.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Jul 2007 23:13:39 +0100

David,

On 17 Jul 2007, at 16:06, [email-masked] wrote:
> More comments inline.
> Yes, although the firewall interaction would still be useful to
> mention as the number of ports that have to be opened for an
> application is a consideration in firewall administration.

I added a sentence.

> Try this - it's mostly a rewrite for clarity, the important structural
> change is describing the involvement of the marker bit before stating
> the restrictions.
>
> OLD:
>    When RTP and RTCP packets are multiplexed onto a single port, they
>    can be distinguished provided: 1) the RTP payload type (PT) values
>    used are distinct from the RTCP packet types used; and 2) for each
>    RTP payload type, PT+128 is distinct from the RTCP packet types  
> used.
>    The first constraint precludes a direct conflict between RTP  
> payload
>    type and RTCP packet type, the second constraint precludes a  
> conflict
>    between an RTP data packet with marker bit set and an RTCP packet.
> NEW:
>    When RTP and RTCP packets are multiplexed onto a single port, the
>    RTCP packet type field occupies the same position in the packet as
>    the combination of the RTP marker (M) bit and the RTP payload type
> (PT).
>    This field can be used to distinguish RTP and RTCP packets when two
>    restrictions are observed: 1) the RTP payload type values used are
>    distinct from the RTCP packet types used; and 2) for each RTP  
> payload
>    type (PT), PT+128 is distinct from the RTCP packet types used.
>    The first constraint precludes a direct conflict between RTP  
> payload
>    type and RTCP packet type, the second constraint precludes a  
> conflict
>    between an RTP data packet with the marker bit set and an RTCP
> packet.

Included - thanks.

> Ok, and please bring the Section 4 text into line with this.

Done, by adding "RTCP packet types in the range 1-191 SHOULD only to  
be used when other values have been exhausted". I also clarified in  
both places that values in the range 224-254 should only be used  
after other values have been assigned.

> Ok, but IANA thinks the RTP static payload type registry is closed.

It's closed to new values, but the existing assignments are still  
valid and used.

> OTOH, if static payload types are a concern, should the current
> 72--76 "reserved for RTCP conflict avoidance" range in the RTP
> payload type registry be expanded to 64--95 or 66--95 to prevent
> conflicts with future RTCP packet type allocations?  That would
> seem like a prudent thing to do.

If new static assignments were allowed, yes, however it's not an  
issue in practice since new assignments have been prohibited for some  
time.

				- + -

Putting all this together, gives the following diff from -05:

10c10
<      docName="draft-ietf-avt-rtp-and-rtcp-mux-05.txt">
---
 >      docName="draft-ietf-avt-rtp-and-rtcp-mux-06.txt">
38c38
<   <date day="21" month="May" year="2007" />
---
 >   <date day="17" month="July" year="2007" />
54,57c54,60
<     separate UDP ports. With increased use of Network Address  
Translation
<     (NAT) this has become problematic, since opening multiple NAT  
pinholes
<     can be costly. This memo discusses how the RTP and RTCP flows  
for a
<     single media type can be run on a single port, to ease NAT  
traversal,
---
 >     separate UDP ports.  With increased use of <xref  
target="RFC3022">Network
 >     Address Port Translation (NAPT)</xref> this has become  
problematic, since
 >     maintaining multiple NAT bindings can be costly. It also  
complicates
 >     firewall administration, since multiple ports must be opened  
to allow
 >     RTP traffic.  This memo discusses how the RTP and RTCP flows  
for a
 >     single media type can be run on a single port, to ease NAT  
traversal
 >     and simplify firewall administration,
144,145c147,151
< <t> When RTP and RTCP packets are multiplexed onto a single port,  
they can
<     be distinguished provided: 1) the RTP payload type (PT) values  
used are
---
 > <t> When RTP and RTCP packets are multiplexed onto a single port,  
the RTCP
 >     packet type field occupies the same position in the packet as the
 >     combination of the RTP marker (M) bit and the RTP payload type  
(PT).
 >     This field can be used to distinguish RTP and RTCP packets  
when two
 >     restrictions are observed: 1) the RTP payload type values used  
are
147,152c153,157
<     type, PT+128 is distinct from the RTCP packet types used. The  
first
<     constraint precludes a direct conflict between RTP payload type  
and
<     RTCP packet type, the second constraint precludes a conflict  
between
<     an RTP data packet with marker bit set and an RTCP packet.  This
<     demultiplexing method works because the RTP payload type and RTCP
<     packet type occupy the same position within the packet. </t>
---
 >     type (PT), PT+128 is distinct from the RTCP packet types  
used.  The
 >     first constraint precludes a direct conflict between RTP  
payload type
 >     and RTCP packet type, the second constraint precludes a conflict
 >     between an RTP data packet with the marker bit set and an RTCP  
packet.
 >     </t>
184c189,191
<     payload types in the range 64-95 are blocked. </t>
---
 >     payload types in the range 64-95 are blocked.  RTCP packet  
types in
 >     the ranges 1-191 and 224-254 SHOULD only be used when other  
values
 >     have been exhausted.  </t>
490a498,507
 > <t> The rules for assignment of RTP RTCP Control Packet Types in  
the RTP
 >     the range 200-223 where possible.  If that range is fully  
occupied,
 >     ranges 1-191 and 224-254. This improves header validity  
checking of
 >     RTCP packets compared to RTP packets or other unrelated  
packets. The
 >     values 0 and 255 are avoided for improved validity checking  
relative to
 >     random packets since all-zeros and all-ones are common values.  
</t>

-- 
Colin Perkins
http://csperkins.org/

---

From: [email-masked]
Date: Mon, 16 Jul 2007 17:35:21 -0400

Summary:

Comments:

Section 1 talks about NAT (Network Address Translation) as a
motivation, but the real motivation appears to be NAPT (NFrom [email-masked] Thu Jul 26 13:29:20 2007
From: [email-masked]
Content-class: urn:content-classes:message
Date: Mon, 16 Jul 2007 17:35:21 -0400
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt

Summary:

Comments:

Section 1 talks about NAT (Network Address Translation) as a
motivation, but the real motivation appears to be NAPT (NFrom [email-masked] Thu Jul 26 13:29:20 2007
From: [email-masked]
Content-class: urn:content-classes:message
Date: Mon, 16 Jul 2007 17:35:21 -0400
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt

Summary:

Comments:

Section 1 talks about NAT (Network Address Translation) as a
motivation, but the real motivation appears to be NAPT (NFrom [email-masked] Thu Jul 26 13:29:20 2007
From: [email-masked]
Content-class: urn:content-classes:message
Date: Mon, 16 Jul 2007 17:35:21 -0400
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt

Summary:

Comments:

   Given these constraints, it is RECOMMENDED to follow the guidelines
   in the RTP/AVP profile [7] for the choice of RTP payload type values,

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: [email-masked]
Date: Tue, 17 Jul 2007 11:06:52 -0400

Thanks,
--David

---

From: [email-masked]
Date: Tue, 17 Jul 2007 11:06:52 -0400

Thanks,
--David

---

From: [email-masked]
Date: Tue, 17 Jul 2007 11:06:52 -0400

Thanks,
--David

---

From: [email-masked]
Date: Tue, 17 Jul 2007 11:06:52 -0400

Colin, 

More comments inline.

OLD:
   When RTP and RTCP packets are multiplexed onto a single port, they
   can be distinguished provided: 1) the RTP payload type (PT) values
   used are distinct from th51a2ff026dcb23465f5379250
X-Mailman-Approved-At: Thu, 26 Jul 2007 13:27:55 -0400
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: RE: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Colin, 

More comments inline.

OLD:
   When RTP and RTCP packets are multiplexed onto a single port, they
   can be distinguished provided: 1) the RTP payload type (PT) values
   used are distinct from th51a2ff026dcb23465f5379250
X-Mailman-Approved-At: Thu, 26 Jul 2007 13:27:55 -0400
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: RE: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Colin, 

More comments inline.

OLD:
   When RTP and RTCP packets are multiplexed onto a single port, they
   can be distinguished provided: 1) the RTP payload type (PT) values
   used are distinct from th51a2ff026dcb23465f5379250
X-Mailman-Approved-At: Thu, 26 Jul 2007 13:27:55 -0400
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: RE: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Colin, 

More comments inline.

OLD:
   When RTP and RTCP packets are multiplexed onto a single port, they
   can be distinguished provided: 1) the RTP payload type (PT) values
   used are distinct from the RTCP packet types used; and 2) for each
   RTP payload type, PT+128 is distinct from the RTCP packet types used.
   The first constraint precludes a direct conflict between RTP payload
   type and RTCP packet type, the second constraint precludes a conflict
   between an RTP data packet with marker bit set and an RTCP packet.
   This demultiplexing method works because the RTP payload type and
   RTCP packet type occupy the same position within the packet.

NEW:
   When RTP and RTCP packets are multiplexed onto a single port, the
   RTCP packet type field occupies the same position in the packet as
   the combination of the RTP marker (M) bit and the RTP payload type
(PT).
   This field can be used to distinguish RTP and RTCP packets when two
   restrictions are observed: 1) the RTP payload type values used are
   distinct from the RTCP packet types used; and 2) for each RTP payload
   type (PT), PT+128 is distinct from the RTCP packet types used.
   The first constraint precludes a direct conflict between RTP payload
   type and RTCP packet type, the second constraint precludes a conflict
   between an RTP data packet with the marker bit set and an RTCP
packet.

values,

Thanks,
--David

---

From: [email-masked]
Date: Tue, 17 Jul 2007 11:33:40 -0400

Colin,

 
------------------------------------------------------------------------
----

     (See RFC 3967 for information about using normative references to
     lower-maturity documents in RFCs)
  ** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted by RFC
4587)

The rtcpssm draft is not a downref, as the I-D tracker says it's
intended to be a proposed standard.

FYI,
--David