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

From: actech <[email-masked]>
Date: Tue, 19 Aug 2008 11:31:37 +0900

Mr.Brim,

Thank you for your comments for 16th version of ATARC payload format.
We agree with almost of your comments, and modified the draft
according to that. However, for one issue (regarding on Fragment Number),
we did not change the draft by the reason described below.

You can see the latest version of ATRAC payload format as
draft-ietf-avt-rtp-atrac-family-17.txt.
If you have further comments on the draft, please let us know.

Regards,

Jun

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

In ATRAC specification, it is described that supported bit-rate is
up to 1.4Mbps. It corresponds to approximately 7500bytes/frame.
So 3-bit counter is sufficient for expressioning Fragment Number,
as far as the MTU size is 1500bytes.
----------------------------------------------------

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Aug 2008 08:19:22 -0600

If we assume that the smallest MTU is 576, would anything need to be  
changed?

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 19 Aug 2008 19:10:28 +0300

Folks,

We just had a design team conference call discussing the SVC payload
draft
(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-13.txt). One
topic discussed was about the decoding order recovery process for the
NI-C and NI-TC modes (specified in section 7.1.2 in
draft-ietf-avt-rtp-svc-13.txt). In this process, a remultiplexing buffer
is used. The remultiplexing buffer takes as input the RTP packets output
from the RTP-level reception process for each of the RTP sessions
involved in the multi-session transmission. The decoding order recovery
process then operates on the remultiplexing buffer. 

The topic discussed was why the ecoding order recovery process does not
operate directly one NAL units from the RTP-level reception buffer of
each RTP session, similarly as in the decoding order recovery process
for the NI-T and NI-TC modes (specified in section 7.1.1 in
draft-ietf-avt-rtp-svc-13.txt), and what is the usefulness of the
related parameters like sprop-mst-interleave-depth and
sprop-remux-buf-req. I have explained the use cases during the
conference call, and was requested to send an email to this mailing with
the explanation, in order to have an open discussion.

So here are the use cases and the use of the parameters related to the
remultiplexing buffer. 

Use case 1: robust scheduling. The sender transmits more important data
in the lower layers conveyed in lower RTP sessions earlier than less
important data in the higher layers conveyed in higher RTP sessions,
thus allowing a better chance to receive more important data, e.g. by
allowing retransmission of the more important data. As a result, the
receiver needs to use extra buffer for higher layer data before starting
the decoding order recovery process. The parameters define the minimum
size of the buffer required. 

Use case 2: constant bitrate transmission. In many application
scenarios, e.g. DVB-H, the pipes for conveying data from different RTP
sessions are of constant bandwidth. However, the instant video bitrates
for different layers are by nature variable over time. This is more true
in SVC. For example, for a video bitstream containing regular random
access points, which are required in multicast and broadcast
applications to enable new comers to tune in and program channel
switching, IDR pictures are typically encoded at the random access
points. For the base layer, which is H.264/AVC compatible, IDR pictures
are true intra pictures. For the enhancement layers, IDR pictures can
still be encoded using inter-layer prediction hence the coded size is
way smaller than the base layer intra picture at the same access unit
(it is common that an intra coded picture is 10 time larger as an inter
coded picture). Therefore, the bitrate of an enhancement layer can be
much smoother than the bitrate of the base layer. As a result, to let
the data pass the pipes, the transmitter has to transmit data of the
base layer after the IDR picture much later than the data of an
enhancement layer at the same access unit. Similarly as above, the
receiver needs to use extra buffer for enhancement layer data before
starting the decoding order recovery process. The parameters define the
minimum size of the buffer required. 

Use case 3: use of NI-MTAP packets. The newly specified NI-MTAP packet
allows aggregation of data from multiple access units in a
non-interleaved manner within a session. However, when the use of
NI-MTAPs is not aligned among all the RTP sessions (e.g. this is always
the case when the base RTP session is RFC 3984 compatible - which is a
requirement per the payload draft), the receiver needs to use extra
buffer for the RTP session that does not use NI-MTAP or that uses
NI-MTAP but aggregating data from less access units before starting the
decoding order recovery process. The parameters define the minimum size
of the buffer required.
 
BR,YK

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Aug 2008 12:54:06 -0400

> If you have further comments on the draft, please let us know.

Thank you, Jun.  My response is below ...

I still make a friendly suggestion that you document that dependency,
because if there is an extension to the ATRAC specification in the
future to support a higher bit rate, this protocol might break.

Scott

---

From: actech <[email-masked]>
Date: Thu, 21 Aug 2008 18:35:42 +0900

Mr.Brim and Mr.Jennings,

Thank you for your comments.

> > If we assume that the smallest MTU is 576, would anything need to be

In order to solve the problem, we have two ways that
- incorporating rollover mechanism
- increasing of bit number for fragment counter(FrgNo)

Incorporating rollover is easy to modify the standard.
However, the determination of right order of the packets are sometimes
impossible if the received packets have the identical FrgNo and
severely reversed or inverted arrival of the packets are occured.

Regarding on increasing of the bit number, appropriate bit number should be
determined considering various MTU size, or assuming some limitation.
In addition, the impact of modification of the draft is not small in
current (our) system.

We are happy if we can have your further comments.

Regards,

Jun

---

From: Scott Brim <[email-masked]>
Date: Thu, 21 Aug 2008 06:37:16 -0400

> We are happy if we can have your further comments.

My suggestion is not to change the specification, but simply to document
the assumption.  For example:

   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.  (Note:
   3 bits is sufficient to avoid Fragment Number rollover given the
   current maximum supported bit-rate in the ATRAC specification.  If
   that changes, the choice of 3 bits for the Fragment Number should be
   revisited.)

---

From: actech <[email-masked]>
Date: Thu, 21 Aug 2008 20:05:21 +0900

Mr.Brim,

Thank you for your comment and suggestion.
We will update the draft reflecting your idea
if we have no other comments.

Best Regards,

Jun