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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Oct 2008 11:36:35 +0200

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 +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 16 Oct 2008 09:44:40 -0700

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>
</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:[email-masked]] 
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:

>From my perspective I haven't seen any strong arguments why the 
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?

Regards

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Oct 2008 11:08:22 +0200

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

Please be clear that I haven't said that it is mandated to use. Only
saying that it should be mandated to support in the protocol. I have
suggested one way of accomplishing this that mandates it usage, but I
have arrived at the conclusion that this may not be the best way of
doing it. Considering the draft version implementations a signalling
function seems an attractive way forward from my perspective.

> 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…

I am aware of these concerns, but how are this equipment going to handle
all the other changes that has been introduced in the protocol as result
of the IESG review? We already made changes to message handling state
machine for example. So, from a standards point of view any
implementation based on the draft two versions ago will not be compliant
with the RFC. They might interoperate or they may not, I don't claim
understanding of all the details of these changes.

The reason for this discussion is to determine if my discuss is a
reasonable one or not. For that we need the views of others.

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 17 Oct 2008 09:30:46 -0700

>> I continue to be concerned about the request to make ECN Full option
>Please be clear that I haven't said that it is mandated to use. Only
saying that it 
>should be mandated to support in the protocol. I have suggested one way
of accomplishing 
>this that mandates it usage, but I have arrived at the conclusion that
this may not 
>be the best way of doing it. Considering the draft version
implementations a signalling 
>function seems an attractive way forward from my perspective.

I'm unclear as to the difference between mandated to support and use.
Whether it is used
or not, we are stating that all implementations must implement the
features and functions
necessary to support the ECN full option. Where I am confused is that
the MUST vs. SHOULD
in RFC 3168 is only pertinent to implementations that claim
interoperability with the said
RFC. Nowhere does it explicitely state that all tunneling protocols MUST
support the RFC.
That said, I think following the recommendations in the RFC, which is a
MUST for the limited
option, and a SHOULD for a full option, is what the current text reads.
I continue to be
confused about why following the recommendations of the RFC is not
sufficient.

>> 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.
>
>I am aware of these concerns, but how are this equipment going to
handle all the 
>other changes that has been introduced in the protocol as result of the
IESG 
>review? We already made changes to message handling state machine for
example. 
>So, from a standards point of view any implementation based on the
draft two 
>versions ago will not be compliant with the RFC. They might
interoperate or they 
>may not, I don't claim understanding of all the details of these
changes.

The primary difference, Magnus, is that to date, none of the changes
have affected the
data plane. All of the changes, whether message element format or
otherwise, have only
affected the control plane, which is typically done in software.

>The reason for this discussion is to determine if my discuss is a
reasonable one or 
>not. For that we need the views of others.
>
Agreed...

PatC

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Oct 2008 11:19:48 +0200

> confused about why following the recommendations of the RFC is not

It says SHOULD for full functionality. So the question is why CAPWAP
protocols does not need implement full functionality? What is the so
reason that you don't need to follow the recommendation that a SHOULD
is? If this was a MAY then I would agree that just implementing the
limited functionality makes you fully compliant. With a SHOULD it is
much more unclear. Yes, you can in certain cases not implement it.
However, what are those reasons. That is what my discuss is about. Do
capwap have good enough reasons?

Regarding the need to implement it is based on that all claiming support
for IP also needs to support ECN. RFC 3168 (ECN) updates RFC 2474
(Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers). From that you can also find that there is a sequence
of obsoletes and updates that lead back to the host requirement specs.

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 20:05:20 -0500

Hi Magnus, 

When we developed the capwap requirements years ago, we wanted to provide for the private corporate internel networks as well as implementations that traverse open IP networks, resulting in some hardware inplementations that target the closed network case.    For this reason, we didn't require full ECN support. 

In order to address your concerns in light of our WG operating procedures, and to prevent causing current implementations to barf, would you agree to allow the spec to require the limited ECN functionality option with text to note that full ECN functionality should be supported in environments that run across the open internet? 

We can then pursue your option to develop full ECN functionality in the next release. 

Would this approach meet your concerns?

Best Regards,
Dorothy

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
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,

So the questions are:

Regards

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Oct 2008 11:26:04 +0200

> Would this approach meet your concerns?

The problem is I don't see how this can be made interoperable. Otherwise
it would be fine. To have the option we need signalling that indicate
what the tunnel egress supports. Otherwise a full functionality ingress
can send to a limited egress and the congestion information are dropped.

Cheers

Magnus Westerlund

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 21 Oct 2008 10:04:22 -0700

> The problem is I don't see how this can be made interoperable.
Otherwise it would be fine. To have the option we need 
> signalling that indicate what the tunnel egress supports. Otherwise a
full functionality ingress can send to a limited 
> egress and the congestion information are dropped.

But regardless of whether signalling is implemented, congestion
information would be dropped. So having the WTP (or AC) send the
information, and hope that the other end can support full functionality,
is the best it can hope for. If the receiver were to signal it only does
limited functionality, then chances are the sending party will not
behave any differently anyhow. The only upside to signalling is to be
able to display the peer's capabilities.

PatC

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 03:42:49 -0500

Hi Magnus and Capwap WG,

As we've defined the capwap protocol, we have interoperability within the enterprise case, which has limited ECN functionality, but is RFC compliant.  Since there exist implementations within the WG community that will cause hardware failure, we won't have any degree of interoperability if we were to postpone the binding specificaton until the SHOULD portion of RFC 3168 is implemented.  

Is there any support for the binding specifcation towards the enterprise case so that we can support interoperability and resolve the final discuss?

I encourge the WG to weigh in on this final discussion point.  We are getting few comments on the list and Magnus has taken the time to document and present congestion concern and the use of ECN.  

Best Regards,
Dorothy

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 2:26 AM
To: Gellert Dorothy (Nokia-CIC/MtView)
Cc: [email-masked]; [email-masked]
Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP

> Would this approach meet your concerns?

The problem is I don't see how this can be made interoperable. Otherwise it would be fine. To have the option we need signalling that indicate what the tunnel egress supports. Otherwise a full functionality ingress can send to a limited egress and the congestion information are dropped.

Cheers

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Oct 2008 08:45:03 -0400

Hi Magnus,

On Oct 21, 2008, at 5:26 AM, Magnus Westerlund wrote:
> Otherwise

The CAPWAP control protocol is designed to be extensible.  We  
anticipate that private
enterprises will include private control messages in their  
implementations, and we
also expect that later standards (new bindings or updated versions of  
the CAPWAP
protocol) will contain additional control messages.

As indicated in section 4.5.1.1 of the base CAPWAP specification:

"When a WTP or AC receives a message with a Message Type Value field  
that is not recognized and is an odd number, the number in the Message  
Type Value Field is incremented by one, and a Response message with a  
Message Type Value field containing the incremented value and  
containing the Result Code message element with the value  
(Unrecognized Request) is returned to the sender of the received  
message. If the unknown message type is even, the message is ignored."

This makes it very easy to add a feature (such as the ability to  
negotiate a different
ECN mode) in a new version of CAPWAP.  If a WTP or AC wishes to  
negotiate use
of a new feature, it would send a message requesting the  feature (use  
of the full
functionality ECN mode) , and wait for a reply from the other end.  If  
the reply contained
a Result Code of "Unrecognized Request", the requestor would know that  
it was not
supported on the remote end and would keep using the default behavior  
(in this case,
limited functionality ECN).

So, I do believe that it would be possible to add the ability to  
negotiate a different
ECN mode to a later version of CAPWAP in an interoperable way.   That  
specification
would presumably include the details such as which end(s) can send the  
request and
how an AC or WTP that implements this feature should respond.

As I indicated in a private message to you before this issue came to  
the list, I have
two issues with adding "full functionality" ECN mode to CAPWAP at this  
time:

(1) RFC 3168 isn't a BCP, and it doesn't state any requirements for  
future IETF protocols.   Typically, the requirements in a Standards  
Track RFC apply to implementations that claim compliance with that  
RFC.  In this case, implementations that claim compliance with RFC  
3168 MUST implement the limited functionality and SHOULD implement the  
full functionality. There are cases where we have written RFCs that do  
place requirements on future IETF specifications, but they are very  
explicit about the fact that they are doing that.  There have been  
several tunneling specs published since RFC 3168 was approved.  Are  
there any other cases where RFC 3168 has been interpreted to apply to  
tunneling specifications?  Were those specifications required to  
include a MUST for the full functionality option?

(2) Even if I did agree that RFC 3168 should apply to CAPWAP, RFC 3168  
claims that there are two viable options for handling ECN in IP-in-IP  
tunnels and that tunnels SHOULD implement the full functionality  
implementation and MUST implement the limited functionality  
implementation.  By telling us to include a MUST for implementation of  
the full functionality in the CAPWAP spec, you are telling us that  
CAPWAP needs to comply with more stringent requirements in this area  
than RFC 3168 places on other IP-in-IP tunnels.  Why do you think that  
makes sense?

In some sense, that is a technicality-based argument, though.  This  
discussion should really be about what is the right technical choice  
for the protocol...

In this case, there are two things that we need to trade off:

- Enabling better ECN functionality
- Allowing CAPWAP to run on existing switch hardware

We are not expecting that companies will produce new hardware products  
just to run CAPWAP.  We are in a situation where most of the  
enterprise switch vendors have something similar to CAPWAP (such as  
LWAPP from Cisco, etc.) that only works between their ACs and WTPs.   
We are trying to standardize a protocol that will allow one vendor's  
AP to work with other vendor's WTPs, eliminating the lock-in that is  
inherent in the current situation and allowing customers to build a  
viable multi-vendor network.

It is essential to the success of the CAPWAP protocol that we do not  
include features in CAPWAP that would require a hardware upgrade to  
deployed ACs and WTPs.  This goal has been the topic of much WG  
discussion, and we've made several significant compromises to ensure  
that CAPWAP will work in its default configuration on all of the  
existing hardware that we are aware of.  Some of these compromises  
have been very significant, more significant IMO than the question of  
which ECN mode(s) we enable, and the WG has consistently chosen the  
path that will allow deployment on existing hardware.

This is _not_ just a situation where people who have already  
implemented CAPWAP are reticent to change their software  
implementations (although we are).  It is a case where requiring us to  
implement the full ECN functionality will have one of two effects:

(1) Vendors will not move to CAPWAP from their current proprietary  
solutions, because they can not develop a compliant implementation on  
their existing deployed hardware and they don't want to leave their  
customers behind.

OR

(2) Vendors will simply ignore our "MUST implement" and it will be  
meaningless.  We will cost our friends (the ones would actually strive  
to meet our requirements) money while not actually achieving anything  
beneficial.  In fact, depending on how the requirement for full  
functionality ECN is specified, this might _create_ an  
interoperability problem rather than resolving one.

I explained, in the first part of this message, how we could add a  
full functionality ECN to CAPWAP later in an interoperable manner.   
Does that resolve your discuss?

Margaret

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 13:40:44 +0100

I think it would be worthwhile people looking at Bob Briscoe's TSVWG draft concerning tunnelling of ECN (draft-ietf-tsvwg-ecn-tunnel-00). It seems to me that what you are proposing doing with CAPWAP will just add yet another level of compatibility problems between tunnel behaviours.

Toby

____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: 22 October 2008 09:43
> To: [email-masked]
> Subject: Re: [Tsvwg] [Capwap] ECN support when tunneling user packets
> inCAPWAP
> 
> Hi Magnus and Capwap WG,
> 
> As we've defined the capwap protocol, we have interoperability within
> the enterprise case, which has limited ECN functionality, but is RFC
> compliant.  Since there exist implementations within the WG community
> that will cause hardware failure, we won't have any degree of
> interoperability if we were to postpone the binding specificaton until
> the SHOULD portion of RFC 3168 is implemented.
> 
> Is there any support for the binding specifcation towards the
> enterprise case so that we can support interoperability and resolve the
> final discuss?
> 
> I encourge the WG to weigh in on this final discussion point.  We are
> getting few comments on the list and Magnus has taken the time to
> document and present congestion concern and the use of ECN.
> 
> Best Regards,
> Dorothy
> 
> 
> > When we developed the capwap requirements years ago, we wanted to
> provide for the private corporate internel networks as well as
> implementations that traverse open IP networks, resulting in some
> hardware inplementations that target the closed network case.    For
> this reason, we didn't require full ECN support.
> >
> > In order to address your concerns in light of our WG operating
> procedures, and to prevent causing current implementations to barf,
> would you agree to allow the spec to require the limited ECN
> functionality option with text to note that full ECN functionality
> should be supported in environments that run across the open internet?
> >
> Otherwise it would be fine. To have the option we need signalling that
> indicate what the tunnel egress supports. Otherwise a full
> functionality ingress can send to a limited egress and the congestion
> information are dropped.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Oct 2008 17:07:59 +0200

Hi Margaret,

I don't agree with your reasoning that RFC 3168 doesn't apply. Because
ECN is a IP fixed header feature, thus something you need to support
when implementing IP. And as the WTP and AC is a tunnel ingress and
egress points this leads to a requirement handle IP tunnel functionality.

The question which I hoped for feedback was the question about how one
interpret the SHOULD use full functionality.

Considering the possibility for upgrade if some one cares this could be
fixed. I am a bit worried that one hasn't enabled this already now, as
the network where ECN is likely to make a difference would be the access
network that exist between the WTP and the AC.

Cheers

Magnus

Margaret Wasserman skrev:
> The CAPWAP control protocol is designed to be extensible.  We anticipate
> that private
> Message Type Value field containing the incremented value and containing
> the Result Code message element with the value (Unrecognized Request) is
> returned to the sender of the received message. If the unknown message
> type is even, the message is ignored."
> 
> As I indicated in a private message to you before this issue came to the
> list, I have
> Track RFC apply to implementations that claim compliance with that RFC. 
> In this case, implementations that claim compliance with RFC 3168 MUST
> implement the limited functionality and SHOULD implement the full
> functionality. There are cases where we have written RFCs that do place
> requirements on future IETF specifications, but they are very explicit
> about the fact that they are doing that.  There have been several
> tunneling specs published since RFC 3168 was approved.  Are there any
> other cases where RFC 3168 has been interpreted to apply to tunneling
> specifications?  Were those specifications required to include a MUST
> for the full functionality option?
> 
> discussion should really be about what is the right technical choice for
> the protocol...
> 
> just to run CAPWAP.  We are in a situation where most of the enterprise
> switch vendors have something similar to CAPWAP (such as LWAPP from
> Cisco, etc.) that only works between their ACs and WTPs.  We are trying
> to standardize a protocol that will allow one vendor's AP to work with
> other vendor's WTPs, eliminating the lock-in that is inherent in the
> current situation and allowing customers to build a viable multi-vendor
> network.
> 
> existing hardware that we are aware of.  Some of these compromises have
> been very significant, more significant IMO than the question of which
> ECN mode(s) we enable, and the WG has consistently chosen the path that
> will allow deployment on existing hardware.
> 
> This is _not_ just a situation where people who have already implemented
> CAPWAP are reticent to change their software implementations (although
> we are).  It is a case where requiring us to implement the full ECN
> functionality will have one of two effects:
> 
> functionality ECN is specified, this might _create_ an interoperability
> problem rather than resolving one.
> 
> I explained, in the first part of this message, how we could add a full
> functionality ECN to CAPWAP later in an interoperable manner.  Does that
> resolve your discuss?
> 
> Margaret
> 
> 
> 

-- 

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Oct 2008 11:26:48 -0400

> network that exist between the WTP and the AC.

In the vast majority of cases where CAPWAP-like functionality is  
deployed today, the AC is an access controller for an enterprise  
wireless network, so there is very little network complexity between  
the WTP and the AC.  In fact, the vast majority of deployments  
probably have _no_ IP routers between the WTP and the AC.  It is not  
clear that there is much functional difference between the two ECN  
deployment modes in those cases.

I agree that congestion may become and issues, though, if CAPWAP is  
deployed with the WTP and AC separated by a complex network topology.   
So, it would be good if we could support full functionality ECN.

However, we really can't require all CAPWAP nodes to implement the  
full functionality ECN mode, because there is already a bunch of  
deployed hardware that won't do it, and we need CAPWAP to work on that  
hardware.  Because the full functionality ECN requires a change in how  
we process every packet, it would require changes in the "data plane"  
-- the low-level hardware that encapsulates and decapsulates the  
CAPWAP data packets.

Is that the need for compatibility with existing hardware that doesn't  
support full functionality ECN a good enough reason to allow us not to  
follow the SHOULD in RFC 3168 and only implement the limited  
functionality ECN mode (which is a MUST)?

If not, what do you suggest we do instead, given the fact that we need  
to run this protocol on hardware that already exists and doesn't  
support the full functionality ECN?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Oct 2008 15:04:58 -0400

Correcting my own typos...

> functionality ECN mode (which is a MUST)?

What I _meant_ to ask is:

Is the need for compatibility with existing hardware (that doesn't  
support ECN in the
"full functionality" mode) a good enough reason not to follow the  
SHOULD in RFC
3168?  CAPWAP already meets the MUST in RFC 3168 of supporting "limited
functionality" ECN.

> support the full functionality ECN?

Sorry,
Margaret

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Oct 2008 10:40:17 +0200

Margaret,

I think you have misinterpreted what I was suggesting as the way
forward. I was suggesting to require a mechanism to indicate which
functionality was in place. Recommend full ECN functionality but let the
legacy nodes use the limited functionality. I wasn't clear on that I
assumed that the legacy nodes would use limited functionality.

I don't know what to really take away from Matt Mathis comment about
that the failure mode may not be particular severe. The question is if
not severe enough to require the signalling mechanism.

Margaret Wasserman skrev:
> "full functionality" mode) a good enough reason not to follow the SHOULD
> in RFC

I think that require a signalling mechanism to indicate what is
implemented together with a recommendation for full ECN functionality is
 reasonable based on a should. I just wished this hadn't come up in this
stage in the process.

>> support the full functionality ECN?

As indicated above.

Cheers

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Oct 2008 10:36:09 -0400

> not severe enough to require the signalling mechanism.

I don't think I've seen Matt Mathis' comment.  Where was it sent?

Margaret

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Oct 2008 16:59:50 +0200

> I don't think I've seen Matt Mathis' comment.  Where was it sent?

TSVWG list only:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg08685.html

Cheers

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Oct 2008 11:10:19 -0400

Hi Magnus,

Just to make sure I understand...

You are asking us to add a new optional message to CAPWAP that will  
enable "full functionality" ECN support (as described in 3168) on the  
CAPWAP data channel.  The default behavior will remain the same as  
described in the current spec ("limited functionality" ECN), and it  
will be up to vendors who implement CAPWAP whether they implement the  
optional message in their products?  If one end of the connection  
supports "full functionality" ECN and the other does not, the  
connection would continue to use the "limited functionality" mode.  Is  
that correct?

If that would allow us to get the document approved, it seems likely  
that we (more specifically Pat) could add this option to the spec, we  
could get it reviewed by the WG, and we could probably have a new  
document ready for publication within a few weeks, as long as no one  
in the WG raises a significant objection. Pat, does that seem doable?

I don't personally believe that the benefit of adding this option will  
be worth the delay.  I don't think that many vendors are likely to  
implement the full functionality option, and I also don't believe that  
full functionality vs. limited functionality ECN will make much  
difference in the situations where CAPWAP is likely to be deployed.   
But, if this is the only way forward, let's not waste any more time  
arguing, let's just do it.

Is there anyone in the WG who has a blocking objection to adding a  
full functionality ECN option (as described in the first paragraph of  
this message) to CAPWAP?

Margaret

>> SHOULD

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 23 Oct 2008 15:00:20 -0700

It is unclear to me that this is what Magnus is proposing - but if it is that simple, yes, I can make the requested change. Magnus, could you please confirm that Margaret's recommendation below would address your discuss?

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 8:10 AM
To: Magnus Westerlund
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP

Hi Magnus,

You are asking us to add a new optional message to CAPWAP that will enable "full functionality" ECN support (as described in 3168) on the CAPWAP data channel.  The default behavior will remain the same as described in the current spec ("limited functionality" ECN), and it will be up to vendors who implement CAPWAP whether they implement the optional message in their products?  If one end of the connection supports "full functionality" ECN and the other does not, the connection would continue to use the "limited functionality" mode.  Is that correct?

If that would allow us to get the document approved, it seems likely that we (more specifically Pat) could add this option to the spec, we could get it reviewed by the WG, and we could probably have a new document ready for publication within a few weeks, as long as no one in the WG raises a significant objection. Pat, does that seem doable?

I don't personally believe that the benefit of adding this option will be worth the delay.  I don't think that many vendors are likely to implement the full functionality option, and I also don't believe that full functionality vs. limited functionality ECN will make much  
difference in the situations where CAPWAP is likely to be deployed.   
But, if this is the only way forward, let's not waste any more time arguing, let's just do it.

Is there anyone in the WG who has a blocking objection to adding a full functionality ECN option (as described in the first paragraph of this message) to CAPWAP?

Margaret

> functionality was in place. Recommend full ECN functionality but let 
> the legacy nodes use the limited functionality. I wasn't clear on that 
> I assumed that the legacy nodes would use limited functionality.
>
>>> Is that the need for compatibility with existing hardware that 
>>> doesn't support full functionality ECN a good enough reason to allow 
>>> us not to follow the SHOULD in RFC 3168 and only implement the 
>>> limited functionality ECN mode (which is a MUST)?
>>
>> support ECN in the "full functionality" mode) a good enough reason 
>> not to follow the SHOULD in RFC 3168?  CAPWAP already meets the MUST 
>> in RFC 3168 of supporting "limited functionality" ECN.
>
> implemented together with a recommendation for full ECN functionality 
> is reasonable based on a should. I just wished this hadn't come up in 
> this stage in the process.
>
>>
>>> If not, what do you suggest we do instead, given the fact that we 
>>> need to run this protocol on hardware that already exists and 
>>> doesn't support the full functionality ECN?
>>
>
> As indicated above.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2008 15:49:51 +0100

Margaret Wasserman skrev:
> described in the current spec ("limited functionality" ECN), and it will
> be up to vendors who implement CAPWAP whether they implement the
> supports "full functionality" ECN and the other does not, the connection
> would continue to use the "limited functionality" mode.  Is that correct?
> 
Yes, but I would voice ECN support as recommend full functionality, but
clearly allowed to do only limited. But otherwise correct.

Cheers

Magnus Westerlund

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Oct 2008 08:20:53 -0700

> > connection would continue to use the "limited functionality" mode.
Is that correct?
> > 
> Yes, but I would voice ECN support as recommend full functionality,
but clearly allowed to do only limited. But otherwise correct.

I continue to be confused with your position. A MUST is not a
recommendation - it is a mandate. A SHOULD is a recommendation. Are you
asking for a MUST or a SHOULD?

PatC

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2008 16:28:48 +0100

> asking for a MUST or a SHOULD?

What I am suggesting is the following:

CAPWAP AC and WTP SHALL implement limited functionality for ECN and is
RECOMMENDED to implement full ECN functionality.

Cheers

Magnus Westerlund

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Oct 2008 09:07:50 -0700

> > recommendation - it is a mandate. A SHOULD is a recommendation. Are 
> > you asking for a MUST or a SHOULD?
> > 
> 

OK, how about:

<proposed text>
4.5.2.  Quality of Service
[...]
   The IP header also includes the Explicit Congestion Notification
   (ECN) bits [RFC3168].  CAPWAP AC and WTP SHALL implement limited
   functionality for ECN and is RECOMMENDED to implement full ECN
   functionality.  In the "limited functionality option" is supported,
   when packets are encapsulated, the the ECN bits in the outer header
   are set to zero (0).  Similarly, upon decapsulation, the receiver
   does not modify the ECN bits in the original station's packet header.

   In "full functionality option", during the encapsulation process, the
   original ECN bits are copied to the outer header.  Similarly, the
   ECN bits of the outer header are copied to the inner header during
the
   decapsulation process.
</proposed text>

PatC

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2008 11:06:43 +0100

>    ECN bits of the outer header are copied to the inner header during

Pat, I think the requirements text is fine. The summary what to do text
is not correct for the full-functionality. I would simply leave a
reference to section 9.1.1 in RFC 3168.

The other part of the solution is how an ingress can learn what the
egress is capable of. We do need something in Configuration status
request and response message (seems most appropriate as this is what
negotiate the transport also) that indicate the capabilities of the
respective end-point in there function as egress. To me it seems a
single bit is enough. ECN limited functionality only (0), Full and
Limited functionality (1).

You know your protocols best, please figure out where to best stick this
information.

Cheers

Magnus Westerlund

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 28 Oct 2008 09:01:49 -0700

> Pat, I think the requirements text is fine. The summary what to do
text is not correct for the full-functionality. I would simply leave a
reference to section 9.1.1 in RFC 3168.
> 
> You know your protocols best, please figure out where to best stick
this information.

OK, right - I omitted the control plane signalling part - my bad. How
about:

<proposed text>

   The IP header also includes the Explicit Congestion Notification
   (ECN) bits [RFC3168].  CAPWAP AC and WTP SHALL implement limited
   functionality for ECN and is RECOMMENDED to implement full ECN
   functionality.  Section 9.1.1 of [RFC3168] provides guidance on
   limited and full functionality for tunneling protocols.

4.6.  CAPWAP Protocol Message Elements
[...]
   ECN Support                                          53

4.6.25.  ECN Support

   The ECN Support message element is sent by both the WTP and the AC to
   indicate their support for the Explicit Congestion Notification (ECN)
   bits, as defined in [RFC3168].

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  ECN Support  |
     +-+-+-+-+-+-+-+-+

   Type:   53 for ECN Support

   Length:   1

   ECN Support:   An 8-bit value representing the sender's support for
      ECN, as defined in [RFC3168].

      0 -  Limited ECN Support

      1 -  Full ECN Support

6.1.  Join Request
[...]
   The following message elements MUST be included in the Join Request
   message.
[...]
   o  ECN Support, see Section 4.6.25

6.2.  Join Response
[...]
   The following message elements MUST be included in the Join Response
   message.
[...]
   o  ECN Support, see Section 4.6.25

14.  Transport Considerations
[...]
   The CAPWAP protocol mandates support of the Explicit Congestion
   Notification (ECN) through a mode of operation named "limited
   functionality option", detailed in section 9.1.1 of [RFC3168].
   Future versions of the CAPWAP protocol should consider mandating
   support for the "full functionality option".

15.  IANA Considerations
[...]
15.7.  CAPWAP Message Element Type

   The Type field in the CAPWAP Message Element header (see Section 4.6)
   is used to identify the data being transported.  The namespace is 16
   bits (0-65535), where the value of zero (0) is reserved and must not
   be assigned.  The values one (1) through 53 are allocated in this
   specification, and can be found in Section 4.5.1.1.

[...]
15.16.  ECN Support

   The ECN Support field in the ECN Support message element (see
   Section 4.6.25) is used by the WTP to represent its ECN Support.  The
   namespace is 8 bits (0-255).  The values zero (0) and one (1) are
   allocated in this specification, and can be found in Section 4.6.25.
   This namespace is managed by IANA and assignments require a Expert
   Review.  IANA will create the ECN Support registry, whose format is:

           ECN Support                      Type Value       Reference
</proposed text>

PatC

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2008 21:30:19 +0100

> OK, right - I omitted the control plane signalling part - my bad. How

Looks mostly okay, see inline below. Thanks for the quick work. I would
appreciate if some people from the capwap WG also did indicate that it
looks okay from a capwap perspective.

>    bits, as defined in [RFC3168].

I think 1 should be "Full and Limited ECN support".

>            ECN Support                      Type Value       Reference

Thanks

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Oct 2008 13:59:09 -0400

> looks okay from a capwap perspective.

Hi Magnus.  We will do a 1 week call for comments on these changes  
with the WG once they are finalized and a new draft is available, and  
before it is published.

Personally, I think this looks fine from a CAPWAP perspective, and I  
hope others will comment as well.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Oct 2008 14:04:54 -0400

I'm okay with this change in general, as I indicated in my last  
message.  I do think some minor editing is needed for grammar, though,  
details in-line:

>   limited and full functionality for tunneling protocols.

The second sentence is not quite right grammatically...  How about  
changing
these this paragraph to:

The IP header also includes the Explicit Congestion Notification (ECN)
bits [RFC3168].  Section 9.1.1 of RFC3168 describes two levels of ECN  
functionality, full
functionality and limited functionality.  CAPWAP ACs and WTPs SHALL  
implement
the limited functionality and are RECOMMENDED to implement the full  
functionality
described in RFC3168.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 29 Oct 2008 11:28:15 -0700

Done, I will resubmit the drafts today and we can start the 1 week WG
Last Call.

OK?

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2008 11:05 AM
To: Pat Calhoun (pacalhou)
Cc: Magnus Westerlund; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Tsvwg] [Capwap] ECN support when tunneling user packets in
CAPWAP

I'm okay with this change in general, as I indicated in my last message.
I do think some minor editing is needed for grammar, though, details
in-line:

The second sentence is not quite right grammatically...  How about
changing these this paragraph to:

The IP header also includes the Explicit Congestion Notification (ECN)
bits [RFC3168].  Section 9.1.1 of RFC3168 describes two levels of ECN
functionality, full functionality and limited functionality.  CAPWAP ACs
and WTPs SHALL implement the limited functionality and are RECOMMENDED
to implement the full functionality described in RFC3168.