Subject: [6lo] Opinions for draft-savolainen-6lo-optimal-transmission-window-00 ?

From: <[email-masked]>
Date: Mon, 7 Apr 2014 12:59:29 +0000

(retransmission with few mods)

At the IETF#89 6lo WG meeting I had following questions regarding http://tools.ietf.org/id/draft-savolainen-6lo-optimal-transmission-window-00.txt (for which the following IPR disclosure has been made: https://datatracker.ietf.org/ipr/1802/ ):

1) Any thoughts on the presented problem?

2) Do you know of other access networks where such costs are present?

3) Any thoughts on the proposed solution and its usefulness?

4) Is the work under the scope of this WG - or would e.g. 6man be better?

I would like to solicit opinions from the WG to the abovementioned question.

-------
Below some additional thoughts from me:

One comment during the WG session was that why the gateway could not postpone a packet. In case of CoAP the default retransmission timeout is 2-3 seconds (ACK_TIMEOUT * ACK_RANDOM_FACTOR). This provides very little room for gateway to maneuver as it has to leave some time for the actual round trip time. If the gateway could add only one second of additional latency, it would not really help at all due 3GPP networks' design. If local nodes would be already transmitting very close to each other they would already avoid the radio activation costs - and if transmitting far from each other, the one second would not make any difference. The postponing would start helping only if packets could be delayed for tens of seconds or minutes (or tens of minutes). But I don't believe clients would be able to accept such latencies without using some delay tolerant protocols.

If packets, such as IP packets or perhaps CoAP packets, would be colored for QoS handling, then things would be different. But that kind of schemes are not in place AFAIK.

Proxies could provide some help, but would come with all the trouble of proxying.

The draft proposal allows window intervals that should apply to several scenarios. 
- For example, if the gateway is a mobile handset with half an hour interval used for waking up internal applications, the handset could share this interval to devices it is acting as gateway for - hence during a single wake-up cycle internal apps would be woken up to do their tricks and served 6lowpan nodes to transmit their resource updates.
- In another example, in some deployment where more frequent updates are needed, a headless battery-powered gateway could configure 30 second window interval for local nodes, and possibly save significantly (e.g. when compared to waking up every 15 seconds due unsynchronized local nodes).

The incentive for 6lowpan nodes (or other types of nodes)  to follow the transmission window guidance for periodic communications is clear: the longer the battery on the gateway lasts, the longer the node using the gateway *has* Internet connectivity..

The proposed solution will help as long as there are at least two periodically communicating nodes:
- a mobile handset with email/IM/etc app and a laptop connected through it (e.g. via WiFi tethering)
- a mobile handset with email/IM/etc and one 6lowpan node connected through it (e.g. via BT tethering)
- a headless gateway and two 6lowpan nodes connected through it (e.g. 802.15.4)

Best regards,

    Teemu