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.