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

[Scott Brim <swb at employees.org>]

On 8/21/08 5:35 AM, actech allegedly wrote:
> Mr.Brim and Mr.Jennings,
> 
> Thank you for your comments.
> 
>>> 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
> 
>>> If we assume that the smallest MTU is 576, would anything need to be
>>> changed?
> 
> 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

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

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt