Discussion on window size

Short description of issue: Discussion of window size

Submitter name: avri doria

Submitter email address: [email protected]

Date first submitted:     030916

Reference: none

Document: base

Comment type: T

Priority: S

Section: 8.1

Rationale/Explanation of issue:   

3.2 of the GSMP requirements brings up window size issues.

Full description of problem:  Another issue from the requirements doc.

> 3.2. Window Size
>
>    The Switch Configuration Message defined in chapter 8.1 in [5]
>    defines a Window size to be used by the controller when sending
>    messages to the switch.  It is not stated if this window should
>    apply to all messages or only to messages that will always generate
>    a reply.

I have several thoughts on this:

- the size given is just a hint to the controller, so in effect it is 
free to do whatever works best for it.  In fact the text goes on to 
suggest the possibility of experimenting with different window size to 
determine heuristically the best window size.

- since all messages can fail and all failures require an 
acknowledgment, it makes sense to me to include all messages.

>
>    If messages that may not generate a reply should be counted against
>    the window a time-out period when they are to be removed from the
>    window should be defined.


- good idea.  This should be added to the text as a recommendation.  
should there be a recommendation on the time out interval?  Is so, what 
should be recommended?

>
>    It is not defined if the window should be cleared when the adjacency
>    is lost and later recovered.
>

Interesting question.  It certainly should be emptied in the case of a 
new adjacency (i.e. a reset of the switch)
In the case of a recovered adjacency, it is a different issue.  Since 
the controller is responsible for determining whether the state in the 
switch matches its view of what the switch state should look like, it 
can use the contents of the window.  I think it is am implementation 
decision unless we establish methods for determining that the state on 
the control plane and switch match.  This has never been a requirement.

any opinions?

Requested change:   

- insert text recommending that all messages MAY be included in window 
utilazation calculations
- insert text say that if all message, including those that don't 
require an ack, are included, then there SHOULD be a timeout timer.
-insert text saying that in the case of a new adjacency, the window 
SHOULD be emptied, and that in the case of of a recovered adjacency It 
MAY be emptied if the information is not needed.

I do not propose adding a method for determining the consistency of the 
state at this point though it may be good to describe some possible 
methods for doing so in chapter 11.  opinions?