Subject: [Gen-art] gen-art review of draft-ietf-avt-rtp-atrac-family-16.txt

From: Scott Brim <[email-masked]>
Date: Tue, 24 Jun 2008 08:47:05 -0400

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avt-rtp-atrac-family-16.txt
Reviewer: Scott Brim
Review Date: 24 June 2008
IESG Telechat date: 02 July 2008

Summary:

This draft is on the right track, but has open issues,
described in the review.

Comments:

This is being submitted as a proposed standard.  Therefore I am asking 
that it be very clear.  My concerns are mainly with what I see as some 
ambiguities and some possible errors in documenting protocol behavior. 
There aren't many so I have left them in the order they occur in the 
draft instead of categorizing them.

1. Introduction

 >    The need for real-time streaming of audio data has grown, and
 >    this document details our efforts in increasing the product and
 >    application space for the ATRAC family of codecs.

This is a draft for a proposed standard technical specification. 
Whether it is motivated by a desire to increase product and application 
space is irrelevant.  I would delete this.

4.5.2 Scalable Multi-Session Streaming

 >    While there may be alternative methods for synchronization of the
 >    layers, it is RECOMMENDED that the timestamp will be used for
 >    synchronizing the base layer with its enhancement. Applications

"It is RECOMMENDED" does not conform to RFC 2119.  This should be a
SHOULD, along with an explanation of the conditions under which it is
reasonable not to implement (so that implementors are not left
guessing).

 >    If the enhancement layer's session data cannot arrive until the
 >    presentation time, the decoder SHALL decode the Base layer
 >    session's data only, ignoring the enhancement layer's data.

Change SHALL to MUST globally.

5.1  Global Structure of Payload Format

 >    The structure of ATRAC Payload is illustrated in Figure 3.  The
 >    RTP payload following the RTP header contains three octet-aligned
 >    data sections.

Only two data sections are described.  Do you mean that the RTP header 
plus ATRAC header section plus payload section form three sections?

5.3.1 Usage of ATRAC Header Section

 >    Fragment Number (FrgNo): 3 bits
 >    In the event of data fragmentation, this value is one for the
 >    first packet, and increases sequentially for the remaining
 >    fragmented data packets. This value SHOULD be zero for an
 >    unfragmented frame.

Earlier it was said: "The ATRAC codec can handle very large frames.  As 
most IP networks have significantly smaller MTU sizes than the frame 
sizes ATRAC can handle ...".  If there can be such a significant 
difference -- and if you want to allow for larger frames in the future 
-- is there special handling for when this 3-bit counter rolls over 
(more than 7 fragments)?  If not, at least mention that you do not 
expect it to roll over -- or that you expect the receiver to be able to 
handle rollovers.

5.3.2.2  Frame Fragmentation

 >    However, if even a single ATRAC frame will not fit into a
 >    complete RTP packet, the ATRAC frame SHOULD be fragmented.

What is the alternative to fragmenting it?  If there is no
alternative, make the SHOULD a MUST.  If there is an alternative, what
is it and under what conditions is it acceptable to do it?  For
example, you might say: ... "the ATRAC frame SHOULD be fragmented unless 
the receiver is non-compliant and has indicated it is incapable of 
receiving fragments, in which case the session MUST be terminated."

 >    As subsequent packets do not contain any new frames, the Number
 >    of Frames field SHOULD be ignored.

Should this SHOULD be a MUST?  I would think so.  If not, under what 
conditions is it acceptable NOT to ignore the Number of Frames field?

6.1  Example Multi-frame Packet

First, NFrames=5 means there are 6 frames in the packet but only 5 are 
shown.

Second, up in 4.5.1 you said: "In multiplexed streaming, the base
layer and enhancement layer are coupled together in each packet,
utilizing only one session as illustrated in Figure 1.  While the
packet may begin with either layer type, the two layer types MUST
interleave."  In this example you show 3 base layer frames, an 
enhancement frame, and then a base layer frame.  Since

   - you have begun interleaving in the middle of a packet, and

   - interleaving can begin with either layer type, and

   - there are no frame numbers,

how can you tell that the enhancement layer frame is not the
_beginning_ of the interleaving, and that it is not associated with
the _following_ base layer frame?  There seem to be some implicit
assumptions that should be made explicit, so that implementors can
avoid incompatibility.

7.5.2  For Media subtype ATRAC-X

 >       The "baseLayer" parameter MUST be the first entry on this
 >       line.  It is RECOMMENDED that the "channelID" parameter be the
 >       next entry.

Again, make this a SHOULD, and explain under what conditions it is
acceptable not to do so.  Why are you allowing implementors NOT to
have channelID be second?  Why do you want them to?

7.5.3  For Media subtype ATRAC Advanced Lossless

 >    o  The Media subtype (payload format name) goes in SDP "a=rtpmap"
 >       as the encoding name.  This SHOULD be followed by the
 >       "sampleRate" (as the RTP clock rate), and then the actual
 >       number of channels regardless of the channelID parameter.

What is the problem if this order isn't followed?  If you have a SHOULD, 
it's good to tell implementors under what conditions it is acceptable 
for them not to do it.  Otherwise you get inconsistent implementations. 
  Some just ignore all SHOULDs.

 > It is RECOMMENDED

Make it a SHOULD, with explanation.

The same comment applies to the uses of RECOMMENDED that follow.  I'll
stop mentioning them.

7.6  Offer-Answer Model Considerations

 >    In order to establish an interoperable transmission framework, an
 >    Offer-Answer negotiation in SDP SHOULD observe the following
 >    considerations.

Under what conditions is it acceptable not to?

7.6.3  For Media subtype ATRAC-X

 >    o  When creating an offer with considerably high requirements
 >       (such as 8 channels at 96kHz), it is RECOMMENDED that the
 >       offer also contain a configuration with lower requirements
 >       (such as a stereo only option).  Although multiple alternative
 >       configurations may be offered, care SHOULD be taken not to
 >       offer too many payload types.

I'm not sure what this SHOULD means.  If this is just a general bit of
advice, make the SHOULD lower case should -- or perhaps just delete
it.  If this is an important guide to implementation, then should the
SHOULD be a MUST?  If so, what specifically do you mean by "too many"?
Is it possible for the offerer to know?  If it should be a SHOULD,
what is the impact of offering too many?  Under what conditions is it
acceptable to offer too many?  When the receiver's capabilities are
not known?

 >       For best performance, we suggest an answer SHALL NOT contain
 >       any values requiring further capabilities than the offer
 >       contains,

"suggest ... SHALL NOT".  Either they MUST NOT or SHOULD NOT, but I
wouldn't just "suggest" a requirement.  What happens if an offer _does_ 
contain further capabilities?

Scott
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art