Subject: Re: [Capwap] Update proposal for Packet formats

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 30 Jun 2006 16:54:49 -0700

Now I'm confused...

> And on your specific question of a "retry bit", I quess I was 
> not clear, because there is NO retry bit in my packet format 
> proposal. 

>       Retry#: The retry number field starts at zero and is incremented
>             for each message with the same value of message ID.
>             After the maximum value is reached, the value wraps back
>             to zero.  The paired response (or acknowledgement) returns
>             the value from the request (or report). Note the size
>             is 4-bits, and thus a maximum of 16 retries can be
>             be currently outstanding.             
>             This field is used to match a request (or report)
>             with its paired response (or acknowledgement) so that
>             accurate round trip operation time can be determined.
>             (DISCUSS: maybe put back here the text about how this
>             works. The examples of operation retries should help.)

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Friday, June 30, 2006 4:17 PM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: RE: [Capwap] Update proposal for Packet formats
> 
> HI,
> 
> Pat, while I appreciate and share your concerns about 
> changes, I believe that there are serious problems in the 
> fragmentation and retry scheme in CAPWAP-01. (I haven't had 
> the time to check to see if this has changed in CAPWAP-02.) 
> I've asked repeatedly for some one to show a timing diagram 
> of this and other issues, but have not seen this. I've only 
> seen responses to the affect "I understand how it works and I 
> don't need a diagram." This type of comment does not verify 
> that all that have read the document have reached a common 
> understanding. Of course, you are well aware of IETF 
> requiring interoperable implementations to demonstrate common 
> understanding for a standards track document to advance.
> 
> Basic issues, such as this should have been addressed and 
> resolved starting at the November IETF, and if needed an 
> interim meeting that the WG didn't have. I'm disappointed.
> The problems still remain. Let's put a spotlight on the 
> issues and see if they are real, imaginary, or somewhere inbetween. 
> 

> 
> On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote:
> > David,
> > 
> > I'm not sure that I understand the justification for making all of 
> > these rather dramatic changes to the protocol, so I'm not sure what 
> > implementation and demonstration would buy us at the IETF. I think 
> > what would be useful instead is to create issues that describe the 
> > actual problem. We can change the protocol until the cows 
> come home, 
> > but in order to maintain some level of sanity, we need to start 
> > getting a little more aggressive about rejecting feature requests.
> > 
> > One comment on the retry number, though. Both sides have to 
> maintain 
> > state anyways, so it's not clear to me that there is any 
> use in this 
> > bit. For instance what do you do if you receive a message with the 
> > "Retry" bit set, but had never received the first one? The 
> bit really 
> > doesn't provide much use in this case. So in any case you need to 
> > maintain a running counter of what's been received & 
> processed, and we 
> > do this through the sequence number field. The reliability 
> part of the 
> > CAPWAP protocol also ensures that packets are retransmitted if not 
> > acknowledged (where your proposal would require that the packet be 
> > re-encrypted because the Retry bit was changed).
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> 
> Regards,
> /david t. perkins
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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