Hugh,
In response to:
>> Forgive my naivete,
but I don't see how an annex titled
>> "Bursting and bunching
considerations" qualifies in
>> response to "references to the existing standards
for
>>
provisioning, admission control, policing and QOS."
The reference shows that all of
these standards are
insufficient to meet the goal of:
"Assuming 75% time-sensitive traffic with arbitrary
topology
and loading
(subject the the aforementioned 75% rule),"
Did you see any flaws
in the timing diagrams?
>> What I (personally) am looking for is a
presentation of the following:
>> 1. The current standards for
provisioning, admission control,
>>
policing and are...
Sorry, I'm not
really a network veteran. I would assume your
reference library or coworkers
could do a much better job than I.
But, if you can do so, I would
certainly include these in the
working paper references or
bibliography.
2. These standards would be applied to our
problem in this way...
>> The working paper illustrates how
the concepts from some
>> of
these standards could be applied. We really can't say
>>
"would" (versus "could"), since this is something for the
>> working
group to decide. This is only a PAR; there is
>> more work to be
done.
>>
3. Some or all of these do not meet our requirements
because...
Between Annex G and Annex D, I
thought that was done.
>>
4. The originators of these standards have responded...
Actually, they haven't. Of course, they have
opportunity
to join/respond to the reflector. But, I have never
perfected
the art of coercing volunteers to work on my
behalf.
>>
5. We think changes to 802.3 (or 802.1 - for their
discussion)
>> will be better
because...
The proposed
revisions meet the following:
"Assuming 75% time-sensitive traffic with arbitrary
topology
and loading (subject
the the aforementioned 75% rule),"
The existing standards do
not.
If you truely need a flawless list of all standards,
complete
with a detailed analysis of
every implementation option,
I can't help you any
more.
DVJ
David,
Forgive my naivete, but I
don't see how an annex titled "Bursting and bunching considerations" qualifies
in response to "references to the existing standards for provisioning,
admission control, policing and QOS."
What I (personally) am looking
for is a presentation of the following:
1. The current standards for
provisioning, admission control, policing and are...
2. These standards
would be applied to our problem in this way...
3. Some or all of these
do not meet our requirements because...
4. The originators of these
standards have responded...
5. We think changes to 802.3 (or 802.1 -
for their discussion) will be better because...
Hugh.
David V
James wrote:
Hugh,
In response to the following statement:
I expect that you, or someone in the study group,
should find the references to the existing standards
for provisioning, admission control, policing and QOS;
demonstrate why they don't meet your needs
Perhaps you missed a previous email?
For convenience, that message from DVJ is repeated below:
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG
[mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of David V James
Sent: Thursday, May 05, 2005 4:17 PM
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
Subject: Re: [RE] Grand master identifier ==>(evolved to)
overprovisioning
Assuming 75% time-sensitive traffic with arbitrary topology
and loading (subject the the aforementioned 75% rule), then
I believe proofs are contained within "Annex G" of:
http://www.ieee802.org3/re_study/material/index.html
In response to the following statement:
and then propose something tangibly different.
Something tangibly different can also be found in:
http://www.ieee802.org3/re_study/material/index.html
But, for this purpose, please exclude Annex G, which
illustrates the need but is not part of the solution.
It meets "tangibly different" in the sence that it meets the
"Assuming 75% time-sensitive traffic with arbitrary topology
and loading (subject the the aforementioned 75% rule)"
criteria and existing standards do no.
Its violates "tangible different" in that the working paper
is evolutionary, not revolutionary, heavily leveraging
concepts and techniques from existing standards. But,
I hope that (in this context) this is a desirable trait.
Cheers,
DVJ
|