Capwap Mailing List: Re: CAPWAP and congestion control

[Pat Calhoun (pacalhou) (pcalhoun]

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

PatC 

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

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:margaret [at] thingmagic.com]
Sent: Thursday, October 04, 2007 8:33 AM
To: Margaret Wasserman
Cc: capwap
Subject: Re: [Capwap] CAPWAP and congestion control


<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




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

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

_________________________________________________________________
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