stds-802-16: sysreq comment, resubmission

[Scott Marin <smarin@spectrapoint.com>]

Thanks for accepting all but one.

Yes the delay definitions, which drive QoS, are important. A poor set of
delay definitions can delay the work of 801.16 substantially because
people will define delay however they choose if at all.

I hoped you'd agree that there are problems with the definitions and
would support working it somehow at the Hawaii meeting.

I expect a wide set of opinions on the issue. The issue needs some
discussion time. 

In order to get the issue accepted, I'm going to change my
recommendation to delete the delay definitions. That approach should at
least get the issue discussed.

[Submitter's Last Name]
Scott
 
[Submitter's First Name]
Marin
 
[Starting Page #]
18
 
[Starting Line #]
4
 
[(T)echnical for Content-Related Material; (E)ditorial for typos,
 grammar, etc.]
T
 
[Detailed Description of Proposed Insertion, Deletion, Change]
Delete the delay defititions, lines 4 through 11.
 
[Reason for Edit]
The delay definitions need improvement. For example, the phrase "ready
to transmit" and "actually begins transmission" can be interpreted in
several way and needs a more precise definition. In addition, the
end-to-end delay from BNI to SNI and SNI to BNI contains functions
outside of the MAC and PHY for which no delay assumptions or allocation
is provided. In Table 1, it's not clear which, if any, of the delay
definitions are being used. The actual delay through the MAC and PHY are
not defined, which is probably the most important definition for 802.16
to get correct. The notion of delay for initially configuring a
connection versus the steady state delay during payload transmission is
not defined.


Brian_Petry@3com.com wrote:
> 
> Hello Scott,
> 
> Thank you for spending time to generate some good comments on the sysreq draft.
> There was one, though, I can't accept because it doesn't specify an explicit
> change to the document (copy below).  Even so, I think this issue is an
> important one and the QoS group needs to finish their work.
> 
> I was actually somewhat dissapointed with the output from the QoS group.  At the
> last session, they tabled some of their work, thinking they would have time at
> another meeting to work things out.  But, Monday afternoon and evening will
> probably (hopefully) be the last sysreq meeting and I doubt the QoS group will
> have time to meet before then.  If you feel strongly about this one, I recommend
> that you make up a reasonable, consistent solution and send me some more
> comments that fix the document.
> 
> -Brian
> 
> [Submitter's Last Name]
> Scott
> 
> [Submitter's First Name]
> Marin
> 
> [Starting Page #]
> 18
> 
> [Starting Line #]
> 4
> 
> [(T)echnical for Content-Related Material; (E)ditorial for typos,
> grammar, etc.]
> T
> 
> [Detailed Description of Proposed Insertion, Deletion, Change]
> Recommend a Ad Hoc group meet to revise the delay definitions.
> 
> [Reason for Edit]
> The delay definitions need improvement. For example, the phrase "ready
> to transmit" and "actually begins transmission" can be interpreted in
> several way and needs a more precise definition. In addition, the
> end-to-end delay from BNI to SNI and SNI to BNI contains functions
> outside of the MAC and PHY for which no delay assumptions or allocation
> is provided. In Table 1, it's not clear which, if any, of the delay
> definitions are being used. The actual delay through the MAC and PHY are
> not defined, which is probably the most important definition for 802.16
> to get correct. The notion of delay for initially configuring a
> connection versus the steady state delay during payload transmission is
> not defined.