RFC 2736 (rfc2736) - Page 3 of 10

Guidelines for Writers of RTP Payload Format Specifications

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   Although fragmentation is not a disastrous phenomenon if it is a rare
   occurrence, relying on IP fragmentation is a bad design strategy as
   it significantly increases the effective loss rate of a network and
   decreases goodput.  This is because if one fragment is lost, the
   remaining fragments (which have used up bottleneck bandwidth) will
   then need to be discarded by the receiver.  It also puts additional
   load on the routers performing fragmentation and on the end-systems
   re-assembling the fragments.

   In addition, it is noted that the transit time between two hosts on
   the Internet will not be constant.  This is due to two effects -
   jitter caused by being queued behind cross-traffic, and routing
   changes.  The former is possible to characterise and compensate for
   by using a playout buffer, but the latter is impossible to predict
   and difficult to accommodate gracefully.

4.  Guidelines

   We identify the following requirements of RTP payload format
   specifications:

   +  A payload format should be devised so that the stream being
      transported is still useful even in the presence of a moderate
      amount of packet loss.

   +  Ideally all the contents of every packet should be possible to be
      decoded and played out irrespective of whether preceding packets
      have been lost or arrive late.

   The first of these requirements is based on the nature of the
   Internet.  Although it may be possible to engineer parts of the
   Internet to produce low loss rates through careful provisioning or
   the use of non-best-effort services, as a rule payload formats should
   not be designed for these special purpose environments.  Payload
   formats should be designed to be used in the public Internet with
   best effort service, and thus should expect to see moderate loss
   rates.  For example, a 5% loss rate is not uncommon.  We note that
   TCP steady state models [3][4][6] indicate that a 5% loss rate with a
   1KByte packet size and 200ms round-trip time will result in TCP
   achieving a throughput of around 180Kbit/s.  Higher loss rates,
   smaller packet sizes, or a larger RTT are required to constrain TCP
   to lower data rates.  For the most part, it is such TCP traffic that
   is producing the background loss that many RTP flows must co-exist
   with.  Without explicit congestion notification (ECN) [8], loss must
   be considered an intrinsic property of best-effort parts of the
   Internet.





Handley & Perkins        Best Current Practice