[Tsvwg] ECN support when tunneling user packets in CAPWAP

[Magnus Westerlund <[e-mail]>]

Hi CAPWAP and TSVWG,

This email is to start off a public discussion about what support for
ECN that the CAPWAP protocol
(http://tools.ietf.org/wg/capwap/draft-ietf-capwap-protocol-specification/)
should have. This is to resolve my Discuss.

For the TSVWG people, the CAPWAP protocol is a control protocol of
wireless termination point (WTP), like 802.11 access points, from access
control (AC). The capwap protocol also have an option to tunnel the
wireless frames within the protocol. It is in this context that the
usage of ECN is relevant. The wireless frames will commonly carry IP
packets. Thus CAPWAP is among other things an IP in IP tunneling
protocol, although with some extra layers in between the two IP.

So the issue here is what support of ECN should exist in the tunneling
mechanism. ECN (RFC 3168) specifies two options for how tunnels can
handle ECN, the full functionality option where ECN is enabled on the
outer IP header and the relevant state at the tunnel egress is copied to
the inner packet. The limited option where the outer header is set as
ECN incapable. With the limited option what could have been a mark if
the inner packet is ECN enabled becomes a packet drop thus lowering the
utility of the ECN function. The ECN specification have the following
wording in section 9.1.1:

   All IP tunnels MUST implement the limited-functionality option, and
   SHOULD support the full-functionality option.

>From my perspective I haven't seen any strong arguments why the protocol
should only support the limited option. CAPWAP is intended to be used in
access networks, that is a common location for congestion. Thus, the
usage of ECN within this network can have real positive impact on the
user applications. Also ECN has been a part of IP at standard track
level since 2001 and continue to ignore this part of the IP for easy of
implementation does not help improve the Internet. Therefore I really
think CAPWAP SHOULD support full ECN. And with SHOULD I see it as there
need to be real good reasons why this shouldn't be supported.

The complications with introducing the full ECN support option at this
stage is two. One, there already exist implementations that uses this
protocol as so far specified (although some updates will be required to
cover other modifications found during the IETF last call and IESG
review). These are likely to operate with limited option as the
specification hasn't discussed ECN at all.

Secondly, there is the interoperability issue between the tunnel ingress
and egress if one is going to have this being configurable. The tunnel
ingress needs to know the support for ECN handling at the tunnel egress.
Thus the capwap protocol would need an extension to carry that
information in each direction. The problem with a full functionality
ingress and limited functionality egress is that packets that should
have been marked or dropped comes through without indication of congestion.

Thus, the best option to take the current implementations into account
and allow for deployment of full functionality where possible would be
to add additional signaling to the CAPWAP protocol to indicate the
capability of the egress to the ingress and configure the ingress
correctly. If this can be introduced in a manner that doesn't make
current implementations barf, then a nice incremental deployment story
exist.

A second way to introduce full ECN functionality is simply to mandate it
and live through a period with functionality failure towards any non
specification compliant device.

So the questions are:

- Does they exist arguments that motivates support of limited ECN
functionality only?

- Further arguments why CAPWAP really should support ECN?

- Am I over interpreting the requirement for supporting ECN?

Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------