Re: [802.3EEESG] On the topic of tranistion time (was Re: [802.3EEESG] Comments on our work from Vern Paxson)
Mike:
I share Geoff's concerns about emerging applications. I believe AVB has
to be designed with EEE in mind, and to be successful, AVB products will
have to be more energy efficient than traditional Ethernet interfaces
are. It might be appropriate for us to initiate a liaison with 802.1 on
EEE assuming PAR approval.
Their sync protocols are latency sensitive, and could be affected by
speed of frame transmission. Their admission/reservation protocols will
probably be based on link bandwidth and obviously a 10:1 downshift in
bandwidth could matter. What we do on "0BASE-T" could affect the
robustness of their sync protocol or it may be something they want to
take advantage of with appropriate fast-start capabilities. Obviously,
we want their creativity looking at EEE in a cooperative way. Geoff's
idea on a "greased packet" is just one possibility that we need them to
start thinking about.
--Bob
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@NORTEL.COM]
Sent: Monday, June 18, 2007 4:10 PM
To: STDS-802-3-EEE@listserv.ieee.org
Subject: Re: [802.3EEESG] On the topic of tranistion time (was Re:
[802.3EEESG] Comments on our work from Vern Paxson)
Mike-
The problem that I have with Vern's look at things is that it is looking
over our shoulders at the past. This may be appropriate for data centers
who services concentrate on best effort services. I am more worried
about
(literally) the other end of the problem. That is, consumer networks at
the
far-end leaves of the network. My expectation is that much of the growth
in
consumer networks will not be from best effort services but rather from
a
variety of services that have medium to stringent QoS requirements.
Vern's numbers won't (I would guess) help us very much on the QoS
services.
On the other hand, the AV Bridging work going on next door is still in
fairly early stages. I would guess that there is still a chance to put
things into the most time sensitive (and especially variability
sensitive)
protocols. This would be (in my imagination) a "grease the path" packet
that would tell the network to come out of lowest power mode. It could
have
an expiration counter in it (much like the one in the PAUSE frame) to
keep
the speed up til the counter expired. Refreshing the counter (by a new
"grease" packet, or a particular kind of volume or traffic) would keep
it
from downshifting.
Geoff
At 03:28 PM 6/18/2007 , Mike Bennett wrote:
>Folks,
>
>Given all of the discussion we've had on transition time and how speed
>changes will impact performance at upper layers, I'm surprised that no
one
>has responded to Vern's comments or asked questions. Especially
regarding
>the first bullet since we've seen a few presentations expressing
concern
>over transitioning speeds in the order of 10 of milliseconds when no
>packet loss is involved. I think it is important that we have as much
of
>this discussion as possible in advance of the July meeting so I
encourage
>you to ask questions and/or make your comments.
>
>Regards,
>
>Mike
>
>Mike Bennett wrote:
>>Folks,
>>
>>I asked Vern, who is well known for his work on TCP, to take a look at
>>our work and comment on it. Please see his comments below. He has
>>joined the reflector so I encourage you to ask him questions if you
have
>>any. BTW, outage means packet loss.
>>
>>Regards,
>>
>>Mike
>>
>>Here are my thoughts:
>>
>> - An outage on the scale of 10s of msec is really no big deal
>> other than for flows that want to go super fast.
>>
>> - Presumably, such outages are rare (e.g., a few an hour). If
that's
>> right, then the likelihood of one of these coinciding with a
>> super-fast flow will generally be quite rare, though obviously
>> in some environments this might not be the case.
>>
>> - In addition, I'd think that one would use such
bandwidth-switching
>> in conjunction with network conditions of light load (at least,
>> when switching to lower bandwidth), which should make a
collision
>> with a super-fast flow even less likely.
>>
>> - The one case of mild worry is an outage during a switch to
>> higher-bandwidth, because it's a fast flow that's motivating
>> the decision to go for higher-speed operation.
>>
>> - My mental model is that in LANs, s**t happens anyway, i.e.,
>> it wouldn't surprise me that a few equivalent such glitches
>> already happen every day, so this isn't seriously altering
>> the landscape.
>>
>> - Ken's simulations are fairly natural first stabs, though not
>> even close to being comprehensive. (And doing it in a
comprehensive
>> fashion would be a *lot* of work.)
>>
>> - But: my own sense is that there's no need to be comprehensive
>> for this.
>>
>> - I don't understand Ken's "PAUSE" control message, but if it's
>> a layer-2 signal then it requires some careful thought, and
>> my intuition is it would turn out to be a bad idea (so if the
>> sense is that this would be *required* for some reason, then
>> it's time to explore it further rather than proceeding).
Related
>> to this, mention of possibly standardizing in the IETF gives me
>> considerable pause.
>>
>> - If you wanted to thoroughly examine these issues, the way to
>> start would be email among the interested parties (e.g., me &
Ken
>> and whoever else), or, better, on one of the relevant mailing
lists.
>> It's not clear to me from your framing whether such
thoroughness
>> is needed at this point.