- From: Tobias Oberstein <tobias.oberstein@tavendo.de>
- Date: Thu, 29 Mar 2012 15:01:59 -0700
- To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- CC: "g_e_montenegro@yahoo.com" <g_e_montenegro@yahoo.com>, "mike@belshe.com" <mike@belshe.com>
Hi Markus, thank you for your detailed explanations! Very welcome. > In this particular case yes, but it is hard for HTTP/2.0 to take into account the > peculiarities of each link layer. Perhaps we could do some kind of BCP or > "mobile networks for dummies" kind of guidance to implementers, though. Should you ever release such "mobile nets for dummies": I hereby order one! ;) > >Hence, the state transitions seem to be not simply based on "traffic == > >0 or != 0", but on an average rate b/s. If traffic rate falls below, > >it'll transition into FACH or IDLE. > > > > Indeed, it can fall into FACH if there are only small packets. Given that the "snappy button" won't arrive in shops soon, I'd be very interested in how do to that "keep radio hot" pinging best. Would you shed some light onto / share info which of the following might influence the state transitions between IDLE, FACH, DCH? * combined up/down avg rate bits/s over say interval of couple of secs * does up vs. down factor in separetely (i.e. could I be done by only doing _down_stream pinging - probably never ponging back? since down is usually less scarce than up) * given same rate bits/s, does it make a diff. whether many small or a few big IP packets travel the line? * only traffic on the leg between mobile device<=>base station is relevant, or are i.e. PDP contexts also teared down on intervals of inactivity I need your "dummies" book! Ideally, it would contain pseudo code for an adaptive, dynamic keep-radio-hot heartbeat algorithm;) Tobias
Received on Thursday, 29 March 2012 22:02:32 UTC