Re: [802.3EEESG] [802.1 - 2977] Fwd: Energy Efficient Ethernet and 802.1
Dan:
I hope you are able to attend the tutorial (it will be Monday evening),
I expect it will alleviate a number of your concerns. While proper
reporting of the current operational speed may be appropriate and in
some cases necessary, I think as you stated before, there are some
things about the objectives for speed change that might reduce your
concerns.
It is an important goal of EEE that the speed change be symmetrical.
Specifically, either end of a link can return the link to its maximum
operational speed. It is also assumed that the control policy for link
speed change will be load sensitive. When the link is lightly utilized,
the link can downshift in speed; and when load increases to justify, the
link will switch to the higher speed. Consequently, there should be no
need to kill some application that might want to use the link or to
inform the network manager so that application layer traffic can be
tuned.
We think this congestion management protocols will be complementary to
the speed change capability, but there may be need or benefit to some
communication of the link speed change.
An admission protocol might benefit from knowledge of the current speed.
Does there need to be any interaction between the control policy or even
a disable of the speed change capability for such admission protocols?
We are also considering zero as a link speed. Some participants see
this as an essential contributor to AVB product success, as standby
power consumption is very important and if not addressed likely to be
regulated. Gigabit links burn far too much power to simply leave them
running 24/7 -- most of the day only sending idles. What is the impact
of the latency change that accompanies a speed change on the
synchronization protocol and how do we reduce negative effects of that
latency change?
We want the switching to happen as quickly as possible, but there are
some engineering realities the EEE project will have to address.
Initial lab work indicates that one can save the parameters used by
1000BASE-T logic and they will still be usable the next morning; but
initial work study of 10GBASE-T indicates that the parameters are not
valid for significant periods of time, the result is either a longer
time to switch or a periodic switching to 10 Gb/s to maintain a useful
training state of the logic. We consider zero a speed, but the zero
speed may have a larger switching time than a gigabit link switching to
100 Mb/s operation, something that will only be known when we pick the
method for implementing this.
If the time to respond to network load is current speed (zero) or up
speed (e.g., 10GBASE-T) dependent, perhaps it is important for higher
layer protocols to know that the link speed has been reduced to conserve
energy.
I believe it is on these kind of issues, and others we may not have
thought of, that we hope to get some advice from 802.1.
--Bob
-----Original Message-----
From: IEEE 802.1 list HELP only [mailto:hdk-36.tk0ck_txg7w@att.net] On
Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, July 11, 2007 2:01 AM
To: STDS-802-1-L@listserv.ieee.org
Subject: Re: [802.1 - 2977] Fwd: Energy Efficient Ethernet and 802.1
IEEE 802.1 ballots: P802.1AR due July 9, P802.1ah July 10, P802.1af July
17
Hi Pat,
See in-line.
Regards,
Dan
> -----Original Message-----
> From: IEEE 802.1 list HELP only
>
> Dan,
>
> I haven't been at all the EEE meetings, but I don't think
> reporting each speed change by SNMP management has been in
> any of the presentations and I don't think it has been
> discussed. In some cases, speed changes could occur
> relatively rapidly compared to the events that are usually
> managed such as links going up and down.
Let us think how the event is reported in a network management
environment. It is possible that not all transient speed changes need to
be reported by SNMP, but when going in energy saving mode it looks to me
that we deal with a change of speed and mode of operation that has a
longer term effect and implications on the behavior of applications and
of the bridges and hosts that are being interconnected by the link. The
comparison with link up and down may not be that exaggerated, as some
applications need to shut down as result of the transition, and the
network manager needs to be informed about the reason. Now what happens
if the link that is affected is on the path to the management station? A
whole part of the network and IT environment shuts down without the
operator at least being warned by a notification?
>
> Would you mind if I forwarded your questions to the EEE
> reflector so that people can think about them before the meeting?
Absolutely, not - please forward and copy me as well, because I am not
subscribed to that list.
>
> Regards,
> Pat
>
---- IEEE 802.1 Email List ----
DELETE THIS FOOTER from copies, forwards, & replies.
List archives (access-controlled) by date:
http://www.ieee802.org/1/private/email2/mail1.html
by thread:
http://www.ieee802.org/1/private/email2/thrd1.html
TG ballot: P802.1AR/D1.0 (Secure Device Identifier)
announcement June 15, due July 9
WG ballot: P802.1ah/D3.6 (Provider Backbone Bridges)
corrected announcement June 25, due July 10
TG ballot: P802.1af/D1.6 (Authenticated Key Agreement for MAC Security)
announcement July 3, due July 17