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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David,

On 17 Jul 2007, at 16:06, Black_David@xxxxxxx wrote:
More comments inline.

Thanks for the review - some comments inline.

On 16 Jul 2007, at 22:35, Black_David@xxxxxxx 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?

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.

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.

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

Included - thanks.

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.

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.

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

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 > Parameters registry are updated as follows. When assigning RTP RTCP > Control Packet types, IANA is requested to assign unused values from > the range 200-223 where possible. If that range is fully occupied, > values from the range 194-199 may be used, and then values from the > 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/



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]