[802.3EEESG] On the topic of tranistion time (was Re: [802.3EEESG] Comments on our work from Vern Paxson)
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.