This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follows ...
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
Document: draft-ietf-payload-g7110-03
Reviewer: David Black
Review Date: October 22, 2014
IETF LC End Date: October 27, 2014
IESG Telechat date: October 30, 2014
Summary: This draft is on the right track, but has open issues
described in the review.
Process note: This is the second draft that I've reviewed recently
that has been scheduled for an IESG telechat almost immediately
following the end of IETF Last Call. The resulting overlap of
IETF LC with IESG Evaluation can result in significant last-minute
changes to the draft when issues are discovered during IETF LC.
This draft describes an RTP payload format for carrying G.711.0
compressed G.711 voice. The details of G.711.0 compression are
left to the ITU-T G.711.0 spec (which is fine), and this draft
focuses on how to carry the compressed results in RTP and conversion
to/from uncompressed G.711 voice at the communication endpoints.
I found a few major issues and a couple of minor ones, although
a couple of the major issues depend on a meta-issue, - the intended
relationship of this draft be to the ITU-T G.711.0 spec.
In general, I expect IETF RFCs to be stand-alone documents that make
sense on their own, although one may need to read related documents
to completely understand what's going on. For this draft, I would
expect the actual compression/decompression algorithms to be left to
the ITU-T spec, and this draft to stand on its own in explaining how
to deploy G.711.0 compression/decompression with RTP. If that
expectation is incorrect, and this draft is effectively an RTP Annex
to G.711.0 that must be read in concert with G.711.0, then the
first two major issues below are not problems as they should be
obvious in the G.711.0 spec, although the fact that this draft is
effectively an Annex to G.711.0 should be stated. Otherwise, those
two major issues need attention.
-- Major Issues (4):
[A] Section 4.2.3 specifies a detailed decoding algorithm covering
how G.711.0 decompression interacts with received RTP G.711.0 payloads.
A corresponding encoding algorithm specification is needed on the
sending side for G.711.0 compression interaction with RTP sending.
The algorithm will have some decision points in it that cannot be
fully specified, e.g., time coverage of the generated G.711.0 frames.
[B] The G.711.0 frame format is not specified here, making it very
difficult to figure out what's going on when G.711.0 frames are
concatenated. A specific example is that the concept of a "prefix
code" that occurs at the start of a G.711.0 frame is far too important
to be hidden in step H5 of the decoding algorithm in Section 4.2.3.
[C] The discussion of use of the SDP ptime parameter is spread out and
imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or
recommended? - it's not obvious).
A specific example is that this sentence in Section 4.2.4 is an
invitation to interoperability problems ("could infer" - how is that
done and where do the inputs to that inference come from?):
Similarly, if the number of
channels was not known, but the payload "ptime" was known, one could
infer (knowing the sampling rate) how many G.711 symbols each channel
contained; then with this knowledge determine how many channels of
data were contained in the payload.
I would suggest that a subsection be added, possibly at the end of
Section 3, to gather/summarize all of the relevant ptime discussion
in one place. I suspect that the contents of this draft are mostly
correct wrt ptime, but it's hard to figure out what's going on from
the current spread-out text. It looks like "ptime" could provide a
cross-check on correctness of G.711.0 decoding - see minor issue [G]
below.
This major issue [C] is independent of the relationship between this
draft and the G.711.0 spec.
[D] Backwards compatibility.
The problem here is that it's not clear that negotiation (e.g., via SDP)
is required. This sentence in Section 3.1 is a particular problem:
G.711.0, being both lossless and stateless, may also be employed as a
lossless compression mechanism anywhere between end systems which
have negotiated use of G.711.
That's definitely wrong. Use of G.711.0 when only G.711 has been
negotiated will fail to interoperate correctly.
A subsection of section 3 on negotiation and SDP usage would help here.
This major issue [D] is independent of the relationship between this
draft and the G.711.0 spec.
-- Minor issues (3):
[E] Section 4.1:
The only significant difference is that the
payload type (PT) RTP header field will have a value corresponding to
the dynamic payload type assigned to the flow. This is in contrast
to most current uses of G.711 which typically use the static payload
assignment of PT = 0 (PCMU) or PT = 8 (PCMA) [RFC3551] even though
the negotiation and use of dynamic payload types is allowed for
G.711.
I would change "will have" to "MUST have" and add the following sentence:
The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0
content.
I'm suspect that this is obvious to the authors, but it'll help a reader
who's not familiar with the importance of the difference between G.711
and G.711.0 .
[F] Section 4.1:
PT - The assignment of an RTP payload type for the format defined
in this memo is outside the scope of this document. The RTP
profiles in use currently mandate binding the payload type
dynamically for this payload format.
Good start, but not sufficient - cite the "RTP profiles currently
in use" and I would expect those citations to be normative references.
Would that be just RFC 3551 and RFC 4585 (both are already normative
references), or are there more RTP profiles?
[G] Framing errors
Section 4 generally assumes that the G.711.0 decoder gets handed frames
generated by the G.711.0 encoder and can't get disaligned. I'm not
convinced that this "just works" based on the text in the draft - major
issue [B] is a significant reason why, and explaining that should help.
Some discussion should be added on why the G.711.0 decoder can't get
disaligned wrt frame boundaries this can't happen, or what the G.711.0
decoder will do when it discovers that it wasn't handed a complete G.711.0
frame. For example, this error case and how to deal with it are not
covered by the algorithm in Section 4.2.3.
-- Nits/editorial comments:
Section 3.2:
A6 Bounded expansion: Since attribute A2 above requires G.711.0 to
be lossless for any payload, by definition there exists at
least one potential G.711 payload which must be
"uncompressible".
The "by definition" statement assumes that every possible bit string is
a valid G.711 input. If that is correct, it should be explicitly stated.
A8 Low Complexity: Less than 1.0 WMOPS average and low memory
footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic
operations) [ICASSP] [G.711.0].
Expand WMOPS on first use, and check for other acronyms that need to be
expanded on first use.
Section 3.3:
Since the G.711.0 output frame is "self-describing", a G.711.0
decoder (process "B") can losslessly reproduce the original G.711
input frame with only the knowledge of which companding law was used
(A-law or mu-law).
"companding law"? The term "compression law" is used elsewhere in
this draft, including two paragraphs earlier in this section - I suggest
using "compression law" consistently.
Section 6:
We note that something must be stored for any G.711.0 frames that not
received at the receiving endpoint, no matter what the cause.
"that not" -> "that are not"
Section 6.2:
An entire frame of value 0++ or 0-- is expected to be
extraordinarily rare when the frame was in fact generated by a
natural signal (on the order of one in 2^{ptime in samples, minus
one}), as analog inputs such as speech and music are zero-mean and
are typically acoustically coupled to digital sampling systems.
This doesn't explain where the 2^{ptime in samples, minus one} order
of magnitude estimation came from. What assumption(s) is(are) being
made about randomness and distribution thereof in the analog input?
It might be simpler to delete the parenthesized text.
Section 11: Congestion Control
This section is mis-named, as it basically (correctly) says that there
is nothing useful that can be done in G.711.0 compression to respond
to congestion. I would retitle this to "Congestion Considerations".
Are there opportunities to respond to congestion elsewhere, e.g.
dynamically change the sampling rate? If so, a sentence mentioning
them would be good to add.
idnits 2.13.01 didn't find anything to complain about ;-).
--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
Most of these questions are N/A as this draft specifies a payload format
for RTP, so most of the operations and management concerns are wrt RTP
and SDP.
A.1.3. Has the migration path been discussed?
No, see major issue [D] above.
A.1.4 Have the Requirements on other protocols and functional
components been discussed?
Only in part - major issues [C] and [D] call out shortcomings in the
discussion of SDP interactions.
A.1.8 Are there fault or threshold conditions that should be reported?
Yes, the likelihood and consequences of framing problems at the G.711.0
decoder (decoder is handed octet strings that are not G.711.0 frames
generated by the encoder) should be discussed. Major issue [B] needs
to be resolved first, and then see minor issue [G].
A.2. Management Considerations
I would expect that the media type registration (Section 5.1 of this draft)
results in this new G.711.0 media type being usable in any relevant
management model and/or framework that has some notion of media type.
A.3 Documentation
By itself, this compressed payload format does not look like a likely
source of significant operational impacts on the Internet.
The shepherd's writeup indicates that an implementation exists.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------