Subject: [Tsvwg] RT-ECN: RFC 3540 Nonce and next steps.

From: [email-masked]
Date: Thu, 29 Sep 2005 13:57:30 -0400

While I could post to move all five of the RT-ECN topics forward,
I think this is the one to focus on:
 
> [David's Concern]
> (2) Probe sequence does not replace function of RFC 3540 nonce.  The
> 	RT-ECN draft requires that the receiver be trusted, and hence the
> 	RT-ECN probe mechanism does not detect a cheating receiver that
> 	fails to return congestion indications to the sender.  Detection
> 	of such a cheating receiver is the primary purpose of RFC 3540.
> 
> [Response]
> The RT-ECN mechanism is for the control of congestion that may be caused
> by real-time inelastic traffic in the network.  This is different to
> what is defined in RFC 3168 and RFC 3540 for several reasons that are
> stated in the draft. 
> 
> RFC 3168 requires that the sender is trusted. With RT-ECN the
> requirement is that the receiver is trusted. In fact due to the
> signaling that is used to setup the session both the sender and the
> receiver are trusted. Since RT-ECN is targeted at application that use
> signaling such as SIP it does not have the issue of receiver cheating
> assuming that appropriate procedures and security recommendation are
> followed for signaling. 

This is indicative of the most important shortcoming of the RT-ECN
draft - it does not lay out the complete framework for use of RT-ECN
and hence overlooks some important aspects, in particular the
interaction with protocols such as SIP and RTP.  The difficulty
in figuring out that the receiver has to be trusted (and hence no
equivalent to RFC 3540 is proposed) is symptomatic of this absence
of framework discussion.

RFC 3168 provides all the details of ECN for TCP - TCP takes care
of ECN negotiation on connection setup and the response to ECN
congestion indications.  All the structure and details are there
- it is sufficient for an implementer to apply RFC 3168 to her
TCP and IP implementations, and she has full ECN functionality
at the endpoints.

In contrast, the RT-ECN draft assumes the use of an application
signaling protocol (e.g., SIP) for ECN negotiation, without specifying
the details of how that negotiation is to be done.  The RT-ECN draft
contains a number of details of how to use an RTP probe format, but
relies on an external draft to actually define that format.  The
RT-ECN draft does not spell out what component on an end system
is actually responsible for congestion response when an ECN
congestion indication is received for a real time flow.

What is needed is a structural discussion that lays out the
structure of the complete RT-ECN implementation including its
important components (signaling protocol, RTP components,
RT-ECN in IP header) and how they interact.  The front part
of the use cases draft would be a good place to do this, and
that's also a good place to explain differences from TCP ECN
such as having to trust the receiver and what sort of "cheating"
needs to be detected.  Based on what I believe I heard in Paris
(that the RTP and SIP communities are not convinced that RT-ECN
is a good idea), I would recommend working on the resulting draft
with those communities first, as if there's no way to negotiate
ECN support or respond to congestion indications, the IP header
support is a waste of time.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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