Re: [8023-POEP] Power management discussions during ad-hoc
Hugh and all,
How sensitive this method would be for time delays between the request
for service and using the service e.g.:
Step 1: PD request higher power then advertised by layer 1.
Step 2: PSE gets the request and send confirmation.
Step 3: PD acknowledge and then use higher power.
In this case a max delay time between steps 1-3 is required to be
specified.
Probably there are more issues however it sounds a good start for
discussion.
Yair
-----Original Message-----
From: owner-stds-802-3-poep@xxxxxxxx
[mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Hugh Barrass
Sent: Monday, April 24, 2006 9:04 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] Power management discussions during ad-hoc
Geoff and others who have replied offline,
You are absolutely correct. Stateless mechanisms are inherently more
robust in noisy channels - that is their main advantage. However,
stateful "cheating" with stateless mechanisms leads to subtle and
annoying bugs that are notoriously difficult to diagnose. That's why
stateless mechanisms should only be used where the intention is
stateless behavior.
Stateful protocols are much more flexible but must be designed for
robustness. In particular, the handshake must be sure and the error
behavior must be properly defined (including the out-of-sync and lost
partner cases that Geoff points out). As part of this, my intention is
to propose a very, very simple state machine with a three-way handshake
mechanism (i.e. "I want to change" - "go ahead and change" - "thank you,
I've changed"). By making the state machines extremely simple we can
outweigh the increased complexity of stateful design.
Hugh.
Geoff Thompson wrote:
> Hugh-
>
> My comments would be along the line of general comments of stateful
> vs. stateless.
>
> Distributed state machines where the various pieces are connected by a
> noisy communications channel are a problem.
>
> Duplicate state machines where the multiple pieces are connected by a
> noisy communications channel need to have a means to cope with:
> - detecting when they get out of sync
> - an established benign behavior to revert to when they get
> out of sync
> - an established benign behavior to revert to when
> communication fails
> (and the assumption has to be that the remote went away)
> The fact that we can generally assume that the channel is not very
> noisy doesn't really help much. You can't depend on it enough.
>
> None of these considerations, in a general sense, go away with
> stateless design.
> However, I think it is a little easier to do.
>
> I hope this helps, at least to spark the discussion.
>
> Geoff
>