Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>