8. Congestion Control Considerations

Diese Seite fasst den entsprechenden Abschnitt von RFC 9993 zusammen und bewahrt RTP payload, MIHS, SDP und IANA-Details.

Congestion control considerations from Section 8 are preserved below.

8.  Congestion Control Considerations

   The general congestion control considerations for transporting RTP
   data apply to MPEG-I haptic data over RTP as well [RFC3550].

   It is possible to adapt network bandwidth usage by adjusting either
   the encoder bit rate or the stream content (e.g., the LOD, body
   parts, actuator frequency range, target device types, and
   modalities).  The considerations in this section are applicable to
   best-effort networks and controlled environments.

   In case of congestion, a receiver or intermediate node MAY prioritize
   independent packets over dependent ones, since the non-reception of
   an independent MIHS unit can prevent the decoding of multiple
   subsequent dependent MIHS units.  In case of congestion, a receiver
   or intermediate node MAY prioritize initialization MIHS units over
   other units, as these contain metadata that is used to reinitialize
   the decoder.  Additionally, a receiver or intermediate node MAY drop
   silent units before other types, as a receiver MAY interpret a
   missing unit as silence.  It is also possible, using the layer field
   of the RTP payload header, to allocate MIHS units to different layers
   based on their content to prioritize haptic data that contributes the
   most to the user experience.  In case of congestion, intermediate
   nodes and receivers SHOULD use the MIHS layer value to determine the
   relative importance of haptic RTP packets.

   Receivers should monitor timestamps and treat gaps as loss of the
   corresponding MIHS units.  MIHS units, as defined in
   [ISO.IEC.23090-31], should be checked for structural integrity
   according to their type.  When CRC16 or CRC32 information is present
   in MIHS units, receivers must validate data integrity, and units
   failing Cyclic Redundancy Checks (CRCs) should be treated as lost.
   Receivers should further monitor indicators of service degradation
   such as unexpected silent gaps, repeated decoder reinitializations,
   or decoding failures.  Receivers should report packet loss to the
   sender using RTCP Receiver Reports [RFC3550] and, when available, may
   report detailed loss and jitter metrics using mechanisms described in
   [RFC4585].