Subject: [Capwap] Issue 18: CAPWAP and congestion control

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 16 Nov 2007 15:33:30 -0800

I am closing this issue as no further comments have been received.

PatC

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

Makes sense to me.

Margaret

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

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

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