Re: [Tsvwg] [Capwap] ECN support when tunneling user packets in CAPWAP

["Pat Calhoun (pacalhou)" <[e-mail]>]

Hi Magnus,

I continue to be concerned about the request to make ECN Full option support mandatory. Just to recap, the current spec currently reads:

<current text>
4.5.2.  Quality of Service
[...]
   The IP header also includes the Explicit Congestion Notification
   (ECN) bits [RFC3168].  When packets received from stations are
   encapsulated by the WTP, the ECN bits are set to zero (0) in the
   outer header.  The WTP does not modify the ECN bits in the original
   station's packet header.  This mode of operation is detailed as the
   "limited functionality option" in [RFC3168].
</current text>

I believe that the text above is consistent with the requirement listed in RFC 3168:

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

I believe that requiring all CAPWAP implementations now support full-functionality today will require some significant changes to existing hardware that is shipping today, which I believe would not be in the best interest of the Internet community. I would prefer we keep the text as-is, and re-examine this question at the next version of the CAPWAP protocol.

PatC
-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Wednesday, October 15, 2008 2:37 AM
To: capwap
Cc: tsvwg
Subject: [Capwap] ECN support when tunneling user packets in CAPWAP

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]
----------------------------------------------------------------------
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap