Subject: Re: [Capwap] CAPWAP and congestion control

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Oct 2007 17:02:54 -0400

<wgchair hat="off">

Personally, I thought we reached a different conclusion from the  
discussion in Chicago.  I thought that we were going to specify a  
mandatory to implement congestion control mechanism that could be  
turned off when administrators know that the traffic on their network  
will be IP-only and/or when they know that all of the traffic on  
their network is generated by systems that implement some type of  
congestion control.

Margaret

On Aug 28, 2007, at 8:00 PM, Pat Calhoun (pacalhou) wrote:

> Any objections before I go ahead and change the spec? Do we want to  
> run this by the transport ADs and advisors?
>
> PatC
>
> From: Abhijit Choudhury (achoudhu)
> Sent: Tuesday, August 07, 2007 4:45 PM
> To: capwap
> Subject: [Capwap] CAPWAP and congestion control
>
> Another issue that the transport A-Ds raised was that
> congestion control needs to be considered for CAPWAP.
> The concern was that in case of congestion in the network,
> packets could get discarded and the sources may not be
> notified or may not realize it. This could lead to
> congestion collapse and fairness issues.
>
> In reality, almost all data traffic being tunneled over
> CAPWAP is IP.  Note that the CAPWAP tunnel is
> between the WTP and AC only. TCP already has its own congestion
> control mechanism between the source and the sink, and
> I'd argue that creating another congestion control loop
> in the path would interfere with TCP's congestion control loop
> and lead to undesirable effects.
>
> I'd suggest we add a Transport Considerations section
> to the CAPWAP spec recommending that non-IP traffic not be
> sent over the Internet when using CAPWPAP.
> Some proposed text is provided below.
>
> Thoughts/comments ?
>
> Thanks,
> Abhijit
>
> -------------PROPOSED TEXT ---------------
>
> Transport Considerations
>
> The CAPWAP protocol does not provide a congestion control mechanism.
> The underlying assumption is that data being tunneled by CAPWAP is
> IP. Since it is essentially a tunneling protocol between two  
> intermediate
> points in the path between the wireless client and the end host, it
> was felt that having a separate congestion control for CAPWAP would
> actually interfere with the congestion control mechanisms already
> in place.
>
> In order to prevent congestion collapse and fairness issues from
> happening in the Internet, it is recommended that non-IP traffic
> not be tunneled over CAPWAP.
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Oct 2007 17:04:41 -0400

<wgchair hat="off">

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 4 Oct 2007 11:33:12 -0400

<chair hat="off">

Still commenting as an individual...

Actually, I've been thinking some more about this, and I think that  
we might want to go with the general approach that Abhijit suggested,  
but be a bit more specific regarding the situation.

For example:

"Transport Considerations

The CAPWAP WG carefully considered the congestion control  
requirements of the CAPWAP protocol, both for the CAPWAP control and  
data channels.

CAPWAP specifies a single-threaded command/response protocol to be  
used on the control channel, and we have specified that an  
exponential back-off algorithm should be used when commands are  
retransmitted.  When CAPWAP runs in its default mode (Local MAC), the  
control channel is the only CAPWAP channel.

However, CAPWAP can also be run in Split MAC mode, in which case  
there will be a DTLS-encrypted data channel between each WTP and the  
AC.  The WG discussed various options for providing congestion  
control on this channel.  However, due to performance problems with  
TCP when it is run over another congestion control mechanism and the  
fact that the vast majority of traffic run over the CAPWAP data  
channel is likely to be congestion-controlled IP traffic, the CAPWAP  
WG felt that specifying a congestion control mechanism for the CAPWAP  
data channel would be more likely to cause problems than to resolve any.

Because there is no congestion control mechanism specified for the  
CAPWAP data channel, it is recommended that non-congestion-controlled  
traffic not be tunneled over CAPWAP.  When a significant amount of  
non-congestion-controlled traffic is expected to be present on a  
WLAN, the CAPWAP connection between the AC and the WTP for that LAN  
should be configured to remain in Local MAC mode."

What do folks think?

Dave Borman, could you comment on whether this decision will be  
acceptable to the Transport ADs?

Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 Oct 2007 13:30:55 -0700

I'm comfortable with this approach.

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 8:33 AM
To: Margaret Wasserman
Cc: capwap
Subject: Re: [Capwap] CAPWAP and congestion control

<chair hat="off">

Actually, I've been thinking some more about this, and I think that we
might want to go with the general approach that Abhijit suggested, but
be a bit more specific regarding the situation.

For example:

The CAPWAP WG carefully considered the congestion control requirements
of the CAPWAP protocol, both for the CAPWAP control and data channels.

CAPWAP specifies a single-threaded command/response protocol to be used
on the control channel, and we have specified that an exponential
back-off algorithm should be used when commands are retransmitted.  When
CAPWAP runs in its default mode (Local MAC), the control channel is the
only CAPWAP channel.

However, CAPWAP can also be run in Split MAC mode, in which case there
will be a DTLS-encrypted data channel between each WTP and the AC.  The
WG discussed various options for providing congestion control on this
channel.  However, due to performance problems with TCP when it is run
over another congestion control mechanism and the fact that the vast
majority of traffic run over the CAPWAP data channel is likely to be
congestion-controlled IP traffic, the CAPWAP WG felt that specifying a
congestion control mechanism for the CAPWAP data channel would be more
likely to cause problems than to resolve any.

Because there is no congestion control mechanism specified for the
CAPWAP data channel, it is recommended that non-congestion-controlled
traffic not be tunneled over CAPWAP.  When a significant amount of
non-congestion-controlled traffic is expected to be present on a WLAN,
the CAPWAP connection between the AC and the WTP for that LAN should be
configured to remain in Local MAC mode."

What do folks think?

Margaret

On Oct 3, 2007, at 5:04 PM, Margaret Wasserman wrote:

> will be IP-only and/or when they know that all of the traffic on their

> network is generated by systems that implement some type of congestion

> control.
>> Another issue that the transport A-Ds raised was that congestion 
>> control needs to be considered for CAPWAP.
>> The concern was that in case of congestion in the network, packets 
>> could get discarded and the sources may not be notified or may not 
>> realize it. This could lead to congestion collapse and fairness 
>> issues.
>>
>> In reality, almost all data traffic being tunneled over CAPWAP is IP.

>> Note that the CAPWAP tunnel is between the WTP and AC only. TCP 
>> already has its own congestion control mechanism between the source 
>> and the sink, and I'd argue that creating another congestion control 
>> loop in the path would interfere with TCP's congestion control loop 
>> I'd suggest we add a Transport Considerations section to the CAPWAP 
>> spec recommending that non-IP traffic not be sent over the Internet 
>> when using CAPWPAP.
>> intermediate points in the path between the wireless client and the 
>> end host, it was felt that having a separate congestion control for 
>> CAPWAP would actually interfere with the congestion control 
>> mechanisms already in place.
>>
>> happening in the Internet, it is recommended that non-IP traffic not 
>> be tunneled over CAPWAP.

---

From: "Puneet Agarwal" <[email-masked]>
Date: Fri, 12 Oct 2007 10:22:05 -0700

Hi Margaret,

The local MAC mode does allow tunneling 802.3 packets between WTP and
AC. Hence I would like to suggest a slight addendum to your comment:

"Because there is no congestion control mechanism specified for the
CAPWAP data channel, it is recommended that non-congestion-controlled
traffic not be tunneled over CAPWAP.  When a significant amount of
non-congestion-controlled traffic is expected to be present on a WLAN,
the CAPWAP connection between the AC and the WTP for that LAN should be
configured to remain in Local MAC mode"
<new added text begin> with Distribution function at the WTP. <new added
text end>

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 8:33 AM
To: Margaret Wasserman
Cc: capwap
Subject: Re: [Capwap] CAPWAP and congestion control

<chair hat="off">

For example:

What do folks think?

Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 12 Oct 2007 11:46:35 -0700

Issue 18 is created to track this, and I am ok with the proposed
changes.

PatC 

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 10:22 AM
To: Margaret Wasserman; Margaret Wasserman
Cc: capwap
Subject: Re: [Capwap] CAPWAP and congestion control

Hi Margaret,

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Thursday, October 04, 2007 8:33 AM
To: Margaret Wasserman
Cc: capwap
Subject: Re: [Capwap] CAPWAP and congestion control

<chair hat="off">

For example:

What do folks think?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 12 Oct 2007 14:47:41 -0400

Makes sense to me.

Margaret

On Oct 12, 2007, at 1:22 PM, Puneet Agarwal wrote:

> used
>> their