Re: [802.3EEESG] On the topic of tranistion time (was Re: [802.3EEESG] Comments on our work from Vern Paxson)
(Sorry for being quiet for a while on this thread, due to a combination
of deadlines + travel)
> 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.
Fair 'nuf - it's indeed the case that I was commenting from a non-QoS
perspective, since that's what my work in the past on network dynamics has
focussed on.
That said, I think there's an important question regarding to what degree
there's a lot to be gained by considering not only non-real-time traffic
like TCP but also soft/adaptive real-time traffic (as Ken mentioned in his
subsequent note). The usual design argument for the latter goes: if you
have a real-time application that's designed for general Internet use,
then it *has* to deal with variable conditions in terms of bandwidth &
loss, because that's what you'll inevitable encounter when running end-to-end
over the Internet. Therefore, any such apps can abide transition outages
if they're within the usual envelope that they're already designed for.
This doesn't mean that all real-time apps will have this property; and
because some might not, that in turn argues for some form of signaling so
those apps can ensure they don't have transition outages imposed on them.
However, presumably such apps already need to use signaling to arrange
their QoS, so it would seem the varying power mechanisms can observe this
signaling (albeit possibly a layering violation) in order to infer when
they should avoid transition outages.
(Also, it's worth working out just how stringent the QoS has to be before
this matters, ala' Ken's comments about small packet end-to-end latencies.)
> This would be (in my imagination) a "grease the path" packet
> that would tell the network to come out of lowest power mode.
That makes sense to me, if it's indeed the case that the outages will
be large enough to matter.
> ... Refreshing the counter (by a new
> "grease" packet, or a particular kind of volume or traffic) would keep it
> from downshifting.
As does that.
In any case, I'll be (briefly) attending the upcoming meeting to discuss
these matters face-to-face, if that will be beneficial.
Vern