Capwap Mailing List: Re: Proposed Resolution for Issue 224/89 (and part of 146)

[Margaret Wasserman (margaret]

<chair hat=off>

I agree with the proposal to add this item to the wish list for  
consideration in a possible later version of CAPWAP.

Margaret

</chair>

On Jan 30, 2007, at 6:44 PM, Pat Calhoun (pacalhou) wrote:

> I agree with Abhijit. Yes, it has taken us three years to get to  
> this point and we need to be focused on what's broken in the  
> protocol vs. wish lists. I would propose we add this to the wish  
> list for the next version of CAPWAP.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> From: Abhijit Choudhury [mailto:abhijit10425 [at] yahoo.com]
> Sent: Monday, January 29, 2007 9:08 PM
> To: Sudhanshu; capwap [at] frascone.com
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and  
> part of 146)
>
> Hi Sudhanshu,
> Please see my responses in-line,.
>
> Thanks,
> Abhijit
>
> ----- Original Message ----
> From: Sudhanshu <sudhanshu.ietf [at] gmail.com>
> To: Abhijit Choudhury <abhijit [at] ieee.org>; capwap [at] frascone.com
> Sent: Monday, January 29, 2007 7:39:16 PM
> Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and  
> part of 146)
>
> Abhijit,
>
>
> Don’t hang on to your calculation of 32 bit per packet in 1G pipe  
> line.
>
>
> CAPWAP is not designed only for the Greenfield deployments. And  
> there will be lots of a/b/g APs which will be supporting CAPWAP, if  
> it ever became a popular standard.
> There will be hardly any AP with real 1G throughput any time soon.  
> Most of them will be supporting max ~ 2xx mbps. And overhead has to  
> be calculated on 2xx Mbps.
>
> [Abhijit]  The 1G link I referred to was the link between the WTP  
> and AC.   The up-link of WTPs will be
>
>               gradually changing over to 10/100/1000 MACs as Gig  
> interfaces on L2/L3 switches become
>
>               ubiquitous.   In that case, no matter what your WTP  
> throughput, the
>
>               CAPWAP encapsulated packet will be transmitted by the  
> WTP towards the AC at 1G rate.  The special
>
>               packet format is reducing the header by 32 bits,  
> which means  32ns is being optimized away on this link.
>
>               You have to justify that that amount of time is worth  
> adding additional code in the data path.
>
>
>
> Not every architecture/every system will support the pure pipe line  
> processing. And in that case, 4 byte DMA back-n-forth may be  
> unnecessary overhead on memory bandwidth and processing both in AP  
> and Switch
>
> [Abhijit]  Typically DMA is done on chunks of data.  Packet  
> descriptors  are often allocated for 32, 64 or 128 bytes at a time.
>
>              It is not clear that reducing your packet length by 4  
> bytes will make much of a difference in storage or
>
>              DMA bandwidth.
>
>
> CAPWAP is not designed for the LAN environment only. In that case  
> 1G bandwidth is a luxury, even in today’s world.
>
> [Abhijit]  Agreed. But you have to look at where the primary use of  
> CAPWAP is going to be.
>
>
> If you to look back and review why after 3+ years, we still don’t  
> have a standard, everybody may have their own opinion. But in the  
> best interest of moving forward, let’s looks for the consensus.
>
>
> [Abhijit]  That is the goal of this mailing list - creating  
> consensus.  All I am saying is that there are
>
>               bigger issues to be finalized before we start  
> discussing optimizations.
>
>
>
> _Suds
>
>
>
> From: Abhijit Choudhury [mailto:abhijit10425 [at] yahoo.com]
> Sent: Sunday, January 28, 2007 10:50 PM
> To: capwap [at] frascone.com
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and  
> part of 146)
>
>
> Folks,
>
>
> I'm sure there are many more optimizations that can be
>
> made in the spec. It's been close to three years since
>
> this WG started, and we still don't have a spec out.
>
> Meanwhile, the WLAN industry has been impatiently waiting
>
> for this standard.  It can be argued that if this spec
>
> is not ratified soon it might lose its relevance.
>
> At this point in time, as a group, we need to
>
> focus on fixing items that need fixing because they
>
> are broken. We cannot afford to spend time
>
> debating "nice-to-have"s and changing perfectly working
>
> items in the spec because we want to make some minor
>
> optimizations.
>
>
> If the packet format in the current spec is broken, we
>
> should surely fix it. If 32 bits on a 1Gig link
>
> is all that is being optimized by this new packet
>
> format and additional code in the data path, I'd argue
>
> that this is not what this WG should be spending its time on.
>
> There are a whole bunch of decisions that need to be made
>
> before this spec can be sent out for last call. We need to
>
> focus on those items and get this spec out asap.
>
> .
>
> Thanks,
>
> Abhijit
>
>
> -----Original Message-----
> From: Jim Murphy [mailto:jmurphy [at] trapezenetworks.com]
> Sent: Friday, January 26, 2007 11:57 PM
> To: Bob O'Hara (boohara)
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and  
> part of
> 146)
>
> Bob,
>
> I see no reason why this optimization can not be used in the control
> channel as well. If so, then the concerns about the data and control
> channel having to be exactly the same are eliminated with the added
> benefit of improved performance in each case.
>
> That said, I think we could improve the format a bit based on feedback
> from Sudhanshu and some new observations based on the idea of packet
> header overlay.
>
> The basic idea is that Version and Type fields are what is needed for
> the "preamble" and exist for every type of packet. However, only
> 8 bits are required. We then define the DTLS shim and CAPWAP Header to
> include the preamble. The resulting format is something like this:
>
> CAPWAP Preamble
>          0
>          0 1 2 3 4 5 6 7
>         +-+-+-+-+-+-+-+-+
>         |Version| Type  |
>         +-+-+-+-+-+-+-+-+
>
>     Version:  A 4 bit field which contains the version of CAPWAP  
> used in
>        this packet.  The value for this draft is zero (0).
>
>     Payload Type:  A 4 bit field which specifies the payload type that
>        follows the preamble header.  Unsupported values MUST be  
> silently
>        dropped. The following values are supported:
>
>        0 -  Clear text.  If the packet is received on the data UDP  
> port,
>           the CAPWAP stack MUST treat this as a clear text CAPWAP data
>           packet.  If received on the control UDP port, the CAPWAP  
> stack
>           MUST treat this as a clear text CAPWAP control packet.   
> If the
>           control packet is not a Discovery Request or Response  
> packet,
>           it is illegal and MUST be dropped.
>
>        1 -  DTLS Payload.  The packet is either a DTLS packet and  
> MAY be
>           a data or control packet, based on the UDP port it was
> received
>           on (see section Section 3.1).
>
> CAPWAP DTLS shim:
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  
> 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version| Type  |                    Reserved
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Or, said slightly differently:
>
> CAPWAP DTLS shim:
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  
> 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         | Preamble      |                    Reserved
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> For the header we then have the following:
>
> CAPWAP Header:
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  
> 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version| Type  |  HLEN   |  RID    |  WBID
> |T|F|L|W|M|K|Flags|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |          Fragment ID          |     Frag Offset         | 
> Rsvd
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Note, Version/Type are the CAPWAP preamble.
>
> Essentially, what we have created a de-multiplexing scheme that has  
> the
> following properties:
>
>   - Its performance characteristics are no worse than those of the -04
>     preamble. In fact, demuxing directly off the preamble type is
>     very attractive from a performance perspective.
>   - It does not waste 32 bits in the clear path case.
>   - It works equally well for the data path and the control path so
>     it is a universal solution.
>   - It provides for a powerful extensibility feature that will enhance
>     the longevity of the protocol.
>
> Other notes:
>
>   - I have transposed RID and HLEN to give the hint of a TLV  
> structure.
>     I think this is a useful concept that we should support in the
>     protocol.
>
>   - I belive the F and L flags could be moved to the Rsvd area of the
>     fragmentation super frame as suggested by David Perkins. This  
> opens
>     up some more flag space in the first super frame.
>
> Thanks,
>
> Jim
>
> Bob O'Hara (boohara) wrote:
> >
> > It's always fun to be part of an exercise to optimize something  
> until
> > it can't be optimized any further, and let's be clear about it.   
> That
> > is what we are doing here.  The current preamble, common to both
> > control and data packets, works.  What is being proposed is to make
> > the data packet preamble as short as possible, by reducing its  
> size by
> 32 bits.
> > This comes at the cost of having the control and data packet formats
> > diverge.
> >
> > Let me propose some reasons for keeping the preamble of the control
> > and data packets the same as they were.
> >
> > 1. A DTLS-protected packet, either control or data, is handled  
> exactly
>
> > the same way to produce the decrypted CAPWAP payload.  This  
> decrypted
> > payload can then be passed to software for processing (either  
> control
> > or
> > data) or can be passed to fast path hardware for data path  
> processing.
> >
> > 2. 32 bits take exactly 32ns to transmit at a gigabit per second,
> > which is likely to be the predominant connection for both WTPs and
> ACs.
> > Optimizing the protocol to save these 32ns is a foolish economy.  Is
> > there a dire cost that we encounter, in order to send these bits?
> >
> > 3. Having two different CAPWAP preambles doubles the cost of
> > development of this portion of the protocol (particularly if the
> > CAPWAP header cracking is done in hardware), doubles the hardware
> > necessary to process this portion of the packet (perhaps even that
> > necessary to process the entire packet), and doubles the number of
> bugs to discover and fix.
> >
> > I believe these practical reasons outweigh the reasons presented for
> > making the change to the header.
> >
> >  -Bob
> >
> > -----Original Message-----
> > From: Jim Murphy [mailto:jmurphy [at] trapezenetworks.com]
> > Sent: Thursday, January 25, 2007 12:19 AM
> > To: capwap [at] frascone.com
> > Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part
> > of
> > 146)
> >
> >
> > Please consider the following alternative proposal to optimize the
> > data channel when no DTLS encryption is present. With this proposal,
> > CAPWAP data channels running in the clear will not require the  
> CAPWAP
> > preamble. However, CAPWAP data channels running DTLS must have the
> > CAPWAP preamble.
> >
> > The CAPWAP preamble is modified as follows:
> >
> > [...]
> >          0                   1                    
> 2                   3
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  
> 8 9 0
>
> > 1
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |Version| Type  |                    Reserved
> > |P|
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [...]
> >      P: Must be 1. Indicates that this is a CAPWAP preamble.
> > [...]
> >
> > The CAPWAP Header is modified as follows:
> >
> > [...]
> >          0                   1                    
> 2                   3
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  
> 8 9 0
>
> > 1
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags
> > |P|
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [...]
> >      P: Must be 0. Indicates that this is a CAPWAP preamble.
> > [...]
> >
> > The basic idea is to overlay the CAPWAP preamble and the first
> > 32 bits of the CAPWAP Header. Note the intentional overlap of the
> > Version field and the P bit. Essentially the P bit is a type  
> indicator
>
> > that indicates the type of super field present. A 1 indicates a  
> CAPWAP
>
> > preamble, a 0 indicates the first 32 bits of the CAPWAP Header.
> >
> > Any data packet on a clear (unencrypted) data channel looks as  
> follows
>
> > (to illustrate the use of the P bit):
> >
> >         CAPWAP Plain Text Data Packet:
> >         +--------------------------------+
> >         | IP  | UDP | CAPWAP | Wireless  |
> >         | Hdr | Hdr | Header | Payload   |
> >         |     |     | P=0    |           |
> >         +--------------------------------+
> >
> > Any data packet on an encrypted data channel or a DTLS session
> > establishment packet looks as follows:
> >
> >          DTLS Secured CAPWAP Data Packet:
> >         +------------------------------------------------------+
> >         | IP  | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
> >         | Hdr | Hdr | p-amble| Hdr  |  Hdr   | Payload  | Trlr |
> >         |     |     | P=1    |      |        |          |      |
> >         +------------------------------------------------------+
> >                               \----- authenticated -----/
> >                                     \------- encrypted --------/
> >
> > A switching entity need only check the CAPWAP Version and then the P
> > bit to determine if the CAPWAP packet needs DTLS processing.
> > If the P but is not set, the switching entity may immediately assume
> > only a CAPWAP header and commences de-encapsulation and possible
> > reassembly processing.
> >
> > This proposal serves the following purposes:
> >
> >   - The CAPWAP preamble is present only when really needed.
> Specifically
> >     to identify CAPWAP packet attributes outside of the DTLS
> encrypted/
> >     authenticated area when DTLS is used.
> >
> >   - Eliminates the waste of 32 bits of header information to  
> convey a
> >     single bit of information when in the clear.
> >
> >   - Allows for the continued use of the CAPWAP preamble for other
> >     purposes, such as DTLS session de-multiplexing to deal with the
> >     issue of QoS reordering. (see earlier email from Mani - The QoS
> DTLS
> >     factor)
> >
> > Please let me know if you have any questions.
> >
> > Thanks,
> >
> > Jim
> >
> > _________________________________________________________________
> > 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
>
>
>
> Never Miss an Email
> Stay connected with Yahoo! Mail on your mobile. Get started!
>
>
>
> Access over 1 million songs - Yahoo! Music Unlimited.
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap