Lwapp Mailing List: Re: Another Way to Think about CAPWAP

[Jim Murphy (jmurphy]

Jerome Moisand wrote:

> Explain?


To the AC each station session is an independent state machine.
The state machine moves from state to state as messages are
passed between the station and the AC. With a datagram based
protocol as LWAPP is currently specified, the loss of a packet
will effect only the station associated with the lost packet.
With a streaming protocol, and assuming a singe TCP session between
the AC and AP, all stations are effected (blocked) by a single
dropped packet. The effects of a dropped or late packet are more
widespread with TCP. A separate TCP session per station does not
scale well.

This problem has been studied in great detail for carrying telephony
signalling over IP networks. A protocol called SCTP was eventually
developed to solve this problem. SCTP would be appropriate for
this application as well. See sigtran for more information.

Thanks,

Jim


> TCP works real well as the transport for COPS, which is one of the most
> real-time & transactional control protocols which has been defined so
> far, I believe. And is used in real-life deployment for policy control
> with tens of policy decisions per second and the management of o(100k)
> policy objects.
>
> Not sure to see the fundamental difference (except that APs would
> clearly have much less policy/control objects to deal with).
>
> -----Original Message-----
> From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com]On
> Behalf Of Jim Murphy
> Sent: Tuesday, November 18, 2003 2:03 PM
> To: Pat R. Calhoun
> Cc: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim
> Murphy; Branislav Meandzija; LWAPP
> Subject: Re: [Lwapp] Another Way to Think about CAPWAP
>
>
>
>
> Pat R. Calhoun wrote:
>
>
> > There are mainly three different types of data that need to go between
>
> > AP and AC.
> > Discovery related messages,  configuration/signaling information and 
> > actual
> > data packets.  Data packet could be voice data and requires QoS. TCP 
> > is not
> > a good transport to transfer this information. For discovery,
> > multicasting is required and TCP is not suitable. For control and 
> > signaling data,
> > either TCP or UDP with application reliability can be adapted.
> >
> > <PRC> For the most part you are correct, but it also depends on the 
> > aggressiveness
> > required for control messages. For instance, if TCP's backoff 
> > algorithm could harm
> > the 802.11 service, then it may not be the right transport.
>
> TCP is not what you want due to head of line blocking.
>
> Jim
>
>
> > PatC
>
>
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp