Subject: RE: [PWE3] [Fwd: Proposed text for SAToP congestion section]

From: Craig White <[email-masked]>
Date: Tue, 3 Jan 2006 14:54:46 -0500

>From my memory, certainly not institutional, but perhaps I should be in one,
this is a case of do like we say, not like we do. The transport working
group certainly doesn't seem to hold up useful work simply because it can't
run over the best-effort Internet.

Case in point, RFC 3189 RTP Payload Format for DV Format Video, this is a
specification for 25Mbps and 50Mbps video streams over RTP, which is over
UDP, hardly "TCP friendly". No mention of congestion control in this
profile.

But to be fair, RTP (RFC 3550) does have a congestion control section that's
about as toothless as our requirements document.

***BEGIN QUOTE***

10. Congestion Control

   All transport protocols used on the Internet need to address

   congestion control in some way [31].  RTP is not an exception, but

   because the data transported over RTP is often inelastic (generated

   at a fixed or controlled rate), the means to control congestion in

   RTP may be quite different from those for other transport protocols

   such as TCP.  In one sense, inelasticity reduces the risk of

   congestion because the RTP stream will not expand to consume all

   available bandwidth as a TCP stream can.  However, inelasticity also

   means that the RTP stream cannot arbitrarily reduce its load on the

   network to eliminate congestion when it occurs.

   Since RTP may be used for a wide variety of applications in many

   different contexts, there is no single congestion control mechanism

   that will work for all.  Therefore, congestion control SHOULD be

   defined in each RTP profile as appropriate.  For some profiles, it

   may be sufficient to include an applicability statement restricting

   the use of that profile to environments where congestion is avoided

   by engineering.  For other profiles, specific methods such as data

   rate adaptation based on RTCP feedback may be required.

*END QUOTE*

Why are we being held to a higher standard? Well since 50Meg isn't that much
bandwidth, maybe the 50M of DV doesn't need to address congestion control.

But then the avt group has another, RFC 3497 for payload of SMPTE 292M
Video, now this one runs at 1.485Gbps, certainly enough to be an issue on
the "Internet" and it does have a congestion section, actually it is
incorporated into the security section.

*BEGIN QUOTE*

 9.  Security Considerations

   RTP sessions using the payload format defined in this specification

   are subject to the security considerations discussed in the RTP

   specification [3] and any appropriate RTP profile (e.g., [4]).

   This payload format does not exhibit any significant non-uniformity

   in the receiver side computational complexity for packet processing

   to cause a potential denial-of-service threat for intended receivers.

   The bandwidth of this payload format is high enough (1.485 Gbps

   without the RTP overhead) to cause potential for denial-of-service if

   transmitted onto most currently available Internet paths.  Since

   congestion control is not possible for SMPTE 292M over RTP flows, use

   of the payload SHOULD be narrowly limited to suitably connected

   network endpoints, or to networks where QoS guarantees are available.

   If QoS enhanced service is used, RTP receivers SHOULD monitor packet

   loss to ensure that the service that was requested is actually being

   delivered.  If it is not, then they SHOULD assume that they are

   receiving best-effort service and behave accordingly.

   If best-effort service is being used, RTP receivers MUST monitor

   packet loss to ensure that the packet loss rate is within acceptable

   parameters and MUST leave the session if the loss rate is too high.

   The loss rate is considered acceptable if a TCP flow across the same

   network path, experiencing the same network conditions, would achieve

   an average throughput, measured on a reasonable timescale, that is

   not less than the RTP flow is achieving.  Since congestion control is

   not possible for SMPTE 292M flows, this condition can only be

   satisfied if receivers leave the session if the loss rate is

   unacceptably high.

***END QUOTE***

Is there perhaps some alternative wording we can borrow from here?
Particularly for addressing our IP "best effort" case. There are a lot of
SHOULD's in this example and as others have pointed out, our "MUST shutdown"
will happen when enough packets are lost.

Sorry to be so long....

-craig

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On Behalf Of

> Stewart Bryant

> Sent: Tuesday, January 03, 2006 1:52 PM

> To: Yaakov Stein

> Cc: pwe3

> Subject: Re: [PWE3] [Fwd: Proposed text for SAToP congestion section]

> Yaakov summarizes the situation well.

> Although the PWE3 WG has been reluctant to address the

> issue of congestion, the issue of congestion has been a

> concern for the Transport ADs since the inception of the

> PWE3 WG. Indeed that is why we were originally placed in

> the Transport Area. As I understand it, there is

> institutional memory of Internet failures due to

> inadequate congestion avoidance by transport protocols,

> so this is a sensitive issue in the transport area.

> Whilst TE can mitigate the problem a number of issues

> remain:

> 1) We cannot constrain how and where TDM PW technology

> is deployed. This is particularly the case where the

> PW is encapsulated in IP (via UDP, L2TP or MPLS/GRE).

> In particular the technology may not be SP deployed.

> 2) Even when TE is used there is the issue of one or more

> unexpected events leading to unanticipated severe

> congestion.

*snip*
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3