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

From: "David T. Perkins" <[email-masked]>
Date: Sat, 1 Jul 2006 10:40:53 -0700 (PDT)

HI,

Well, I think there are differences between a "retry bit",
and a "retry number field" that is an integer and has
range of 0 to 16. Small misunderstandings can be the source
for non interoperation. Interoperation is the number one
priority of the IETF, and one of the most important
reasons why IETF technology has exploded in usage from
the late 80s.

I hope we can work out the tradeoffs of this field.
I thought that I had explained it in the document.
I must have been a little skimpy.

I hope we can work this out, and develop interoperable
implementations showing basic operation of the CAPWAP
protocol. Otherwise, I suggest the WG be disbanded.
If there is not enough commitment to achieve demonstration
of basic interoperability then why would we expect
demonstration of interoperability of all features,
which is required for advancement on the standards
track of the specification. Development of a
specification that does not have interoperability
is no benefit to the IETF community.

Regards,
/david t. perkins

On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote:
> 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