[RTG-DIR] RtgDir Review: draft-ietf-lwig-energy-efficient-08.txt

["Acee Lindem (acee)" <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-lwig-energy-efficient-08.txt
Reviewer: Acee Lindem
Review Date: 01/18/17
IETF LC End Date: Finished - Telechat on 01/25/18
Intended Status: Informational

Summary:
    I have some minor concerns about this document that I think should be resolved before publication. Additionally, the document is somewhat hard to read if one is not very familiar with the subject matter.

Comments: The document provides an overview of lower-level techniques for reducing power consumption and then discusses how transport, routing, and one application, CoAP can use lower layer awareness to reduce energy consumption. Since the draft surveys so many different lower layer technologies and IETF protocols, its main value may the introduction and references for further understanding.

Major Issues: No major issues found.

Minor Issues: I have the following minor questions and issues.

        1. The document should define early what constitutes a lower layer versus a higher layer. For example, does lower layer always imply physical or link layer?

        2. In section 3.1, the section on channel sampling refers to a preamble of given duration. However, packets are measured in bits and bytes as opposed to a time interval.
        3. In section 3.3, the first paragraph refers to "such networks" when the statement is in the context of applications.

        4. In sections 4 and 5, are any situations where transport and routing tuning parameters are derived directly from cross-layer communications? I guess I was disappointed that I didn't see this.


Nits: Section 3 is very hard for a someone who is not familiar with RDC techniques to read. Below are a number of editorial suggestions. Note that I've used the RFC Style for punctuation including the additional of the Oxford comma.

ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-lwig-energy-efficient-08.txt.orig draft-ietf-lwig-energy-efficient-08.txt
*** draft-ietf-lwig-energy-efficient-08.txt.orig                               2018-01-15 14:04:20.000000000 -0500
--- draft-ietf-lwig-energy-efficient-08.txt                                    2018-01-18 19:44:31.000000000 -0500
***************
*** 118,131 ****
     supplies for the potentially large number of constrained devices.  In
     such deployment scenarios, it is necessary to optimize the energy
     consumption of the constrained devices.  In this document we describe
!    techniques that are in common use at Layer 2 and at Layer 3, and we
     indicate the need for higher-layer awareness of lower-layer features.

     Many research efforts have studied this "energy efficiency" problem.
     Most of this research has focused on how to optimize the system's
     power consumption in certain deployment scenarios, or how an existing
     network function such as routing or security could be more energy-
!    efficient.  Only few efforts have focused on energy-efficient designs
     for IETF protocols and standardized network stacks for such
     constrained devices [I-D.kovatsch-lwig-class1-coap].

--- 118,131 ----
     supplies for the potentially large number of constrained devices.  In
     such deployment scenarios, it is necessary to optimize the energy
     consumption of the constrained devices.  In this document we describe
!    techniques that are in common use at Layer 2 and Layer 3, and we
     indicate the need for higher-layer awareness of lower-layer features.

     Many research efforts have studied this "energy efficiency" problem.
     Most of this research has focused on how to optimize the system's
     power consumption in certain deployment scenarios, or how an existing
     network function such as routing or security could be more energy-
!    efficient.  Only a few efforts have focused on energy-efficient designs
     for IETF protocols and standardized network stacks for such
     constrained devices [I-D.kovatsch-lwig-class1-coap].

***************
*** 144,150 ****
     layers.  Cross-layer interaction is therefore considered in this
     document from this specific point of view.  Providing further design
     recommendations that go beyond the layered protocol architecture is
!    out of the scope of this document.

     After reviewing the energy-efficient designs of each layer, we
     summarize the document by presenting some overall conclusions.
--- 144,150 ----
     layers.  Cross-layer interaction is therefore considered in this
     document from this specific point of view.  Providing further design
     recommendations that go beyond the layered protocol architecture is
!    beyond the scope of this document.

     After reviewing the energy-efficient designs of each layer, we
     summarize the document by presenting some overall conclusions.
***************
*** 300,306 ****
     the wireless medium, it synchronizes transmission and/or reception
     requests from the higher layers.

!    MAC and RDC are not in the scope of the IETF, yet lower layer
     designers and chipset manufacturers take great care to save energy.
     By knowing the behaviors of these lower layers, IETF engineers can
     design protocols that work well with them.  The IETF protocols to be
--- 300,306 ----
     the wireless medium, it synchronizes transmission and/or reception
     requests from the higher layers.

!    MAC and RDC are not in the scope of the IETF, yet lower-layer
     designers and chipset manufacturers take great care to save energy.
     By knowing the behaviors of these lower layers, IETF engineers can
     design protocols that work well with them.  The IETF protocols to be
***************
*** 315,328 ****

     a) Channel sampling.  In this solution, the radio interface of a
     device periodically monitors the channel for very short time
!    intervals (i.e. with a low duty cycle) with the aim of detecting
     incoming transmissions.  In order to make sure that a receiver can
     correctly receive a transmitted data unit, the sender may prepend a
     preamble of a duration at least the sampling period to the data unit
     to be sent.  Another option for the sender is to repeatedly transmit
     the data unit, instead of sending a preamble before the data unit.
     Once a transmission is detected by a receiver, the receiver may stay
!    awake until the complete reception of the data unit.  Examples of
     radio technologies that use preamble sampling include ContikiMAC, the
     Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the
     Frequently Listening (FL) mode of ITU-T G.9959 [G9959].
--- 315,328 ----

     a) Channel sampling.  In this solution, the radio interface of a
     device periodically monitors the channel for very short time
!    intervals (i.e., with a low duty cycle) with the aim of detecting
     incoming transmissions.  In order to make sure that a receiver can
     correctly receive a transmitted data unit, the sender may prepend a
     preamble of a duration at least the sampling period to the data unit
     to be sent.  Another option for the sender is to repeatedly transmit
     the data unit, instead of sending a preamble before the data unit.
     Once a transmission is detected by a receiver, the receiver may stay
!    awake until the reception of the data unit is completed.  Examples of
     radio technologies that use preamble sampling include ContikiMAC, the
     Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the
     Frequently Listening (FL) mode of ITU-T G.9959 [G9959].
***************
*** 345,351 ****
     example of a radio technology based on this mechanism.

     c) Listen after send.  This technique allows a node to remain in
!    sleep mode by default, wake up and poll a sender (which must be ready
     to receive a poll message) for pending transmissions.  After sending
     the poll message, the node remains in receive mode, ready for a
     potential incoming transmission.  After a certain time interval, the
--- 345,351 ----
     example of a radio technology based on this mechanism.

     c) Listen after send.  This technique allows a node to remain in
!    sleep mode by default, and wake up and poll a sender (which must be ready
     to receive a poll message) for pending transmissions.  After sending
     the poll message, the node remains in receive mode, ready for a
     potential incoming transmission.  After a certain time interval, the
***************
*** 367,373 ****
     On the other hand, due to the latency increase of duty-cycling, a
     sender waiting for a transmission opportunity may need to store
     subsequent outgoing packets in a buffer, increasing memory
!    requirements and potentially incurring queuing waiting time that
     contributes to the packet's overall delay and increases the
     probability of buffer overflow, leading to losses.

--- 367,373 ----
     On the other hand, due to the latency increase of duty-cycling, a
     sender waiting for a transmission opportunity may need to store
     subsequent outgoing packets in a buffer, increasing memory
!    requirements and potentially incurring queue waiting time that
     contributes to the packet's overall delay and increases the
     probability of buffer overflow, leading to losses.

***************
*** 401,407 ****
     requirements.  On the other hand, upper layers should take into
     account the expected latency and/or throughput behavior due to RDC.
     The next subsection provides details on key parameters controlling
!    RDC mechanisms, and thus fundamental trade-offs, for various examples
     of relevant low-power radio technologies.

  3.5.  Packet bundling
--- 401,407 ----
     requirements.  On the other hand, upper layers should take into
     account the expected latency and/or throughput behavior due to RDC.
     The next subsection provides details on key parameters controlling
!    RDC mechanisms, and thus, fundamental trade-offs for various examples
     of relevant low-power radio technologies.

  3.5.  Packet bundling
***************
*** 409,415 ****
     Another technique that may be useful to increase communication energy
     efficiency is packet bundling.  This technique, which is available in
     several radio interfaces (e.g.  LTE and some 802.11 variants), allows
!    to aggregate several small packets into a single large packet.
     Header and communication overhead is therefore reduced.

  3.6.  Power save services available in example low-power radios
--- 409,415 ----
     Another technique that may be useful to increase communication energy
     efficiency is packet bundling.  This technique, which is available in
     several radio interfaces (e.g.  LTE and some 802.11 variants), allows
!    aggregation of several small packets into a single large packet.
     Header and communication overhead is therefore reduced.

  3.6.  Power save services available in example low-power radios
***************
*** 429,435 ****
     Listen Interval (which can be a multiple of the Beacon Interval) in
     order to receive beacons.  The AP signals in the beacon whether there
     is data pending for the station or not.  If there are not frames to
!    be sent to the station, the latter may get back to sleep mode.
     Otherwise, the station may send a message requesting the transmission
     of the buffered data and stay awake in receive mode.

--- 429,435 ----
     Listen Interval (which can be a multiple of the Beacon Interval) in
     order to receive beacons.  The AP signals in the beacon whether there
     is data pending for the station or not.  If there are not frames to
!    be sent to the station, the latter may go back to sleep mode.
     Otherwise, the station may send a message requesting the transmission
     of the buffered data and stay awake in receive mode.

***************
*** 472,495 ****

     Using the above services provided by the lower layer, the constrained
     nodes can achieve either client initiated power save (via TFS) or
!    network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS).

!    Upper layer protocols should synchronize with the parameters such as
     FMS interval and BSS MAX Idle Period, so that the wireless
     transmissions are not triggered periodically.

  3.6.2.  Power Save Services Provided by Bluetooth LE

!    Bluetooth LE is a wireless low-power communications technology that
     is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2
!    specifications [Bluetooth42].  BT-LE has been designed for the goal
!    of ultra-low-power consumption.  IPv6 can be run IPv6 over Bluetooth
     LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668].

     Bluetooth LE networks comprise a master and one or more slaves which
     are connected to the master.  The Bluetooth LE master is assumed to
     be a relatively powerful device, whereas a slave is typically a
!    constrained device (e.g. a class 1 device).

     Medium access in Bluetooth LE is based on a Time Division Multiple
     Access (TDMA) scheme which is coordinated by the master.  This device
--- 472,495 ----

     Using the above services provided by the lower layer, the constrained
     nodes can achieve either client initiated power save (via TFS) or
!    network-assisted power save (Proxy-ARP, BSS Max Idel Period and FMS).

!    Upper layer protocols should synchronize the parameters such as
     FMS interval and BSS MAX Idle Period, so that the wireless
     transmissions are not triggered periodically.

  3.6.2.  Power Save Services Provided by Bluetooth LE

!    Bluetooth LE (BT-LE) is a wireless low-power communications technology that
     is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2
!    specifications [Bluetooth42].  BT-LE has been designed with the goal
!    of ultra-low-power consumption.  IPv6 can be run over Bluetooth
     LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668].

     Bluetooth LE networks comprise a master and one or more slaves which
     are connected to the master.  The Bluetooth LE master is assumed to
     be a relatively powerful device, whereas a slave is typically a
!    constrained device (e.g., a class 1 device).

     Medium access in Bluetooth LE is based on a Time Division Multiple
     Access (TDMA) scheme which is coordinated by the master.  This device
***************
*** 512,518 ****

     The time between consecutive connection events is defined by the
     connInterval parameter, which may range between 7.5 ms and 4 s.  The
!    slave may remain in sleep mode since the end of its last connection
     event until the beginning of its next connection event.  Therefore,
     Bluetooth LE is duty-cycled by design.  Furthermore, after having
     replied to the master, a slave is not required to listen to the
--- 512,518 ----

     The time between consecutive connection events is defined by the
     connInterval parameter, which may range between 7.5 ms and 4 s.  The
!    slave may remain in sleep mode from the end of its last connection
     event until the beginning of its next connection event.  Therefore,
     Bluetooth LE is duty-cycled by design.  Furthermore, after having
     replied to the master, a slave is not required to listen to the
***************
*** 525,535 ****

     Upper layer protocols should take into account the medium access and
     duty-cycling behavior of Bluetooth LE.  In particular, connInterval,
!    connSlaveLatency and connSupervisionTimeout determine the time
     between two consecutive connection events for a given slave.  The
     upper layer packet generation pattern and rate should be consistent
     with the settings of the aforementioned parameters (and vice versa).
!    For example, assume connInterval=4 seconds, connSlaveLatency=7 and
     connSupervisionTimeout=32 seconds.  With these settings,
     communication opportunities between a master and a slave will occur
     during a given interval every 32 seconds.  Duration of the interval
--- 525,535 ----

     Upper layer protocols should take into account the medium access and
     duty-cycling behavior of Bluetooth LE.  In particular, connInterval,
!    connSlaveLatency, and connSupervisionTimeout determine the time
     between two consecutive connection events for a given slave.  The
     upper layer packet generation pattern and rate should be consistent
     with the settings of the aforementioned parameters (and vice versa).
!    For example, assume connInterval=4 seconds, connSlaveLatency=7, and
     connSupervisionTimeout=32 seconds.  With these settings,
     communication opportunities between a master and a slave will occur
     during a given interval every 32 seconds.  Duration of the interval
***************
*** 546,555 ****
     the de-facto choice for a wide range of constrained node network
     application domains and has been a primary target technology of
     various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775],
!    [RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture].  IEEE 802.15.4
     specifies a variety of related PHY and MAC layer functionalites.

!    IEEE 802.15.4 defines three roles called device, coordinator and
     Personal Area Network (PAN) coordinator.  The device role is adequate
     for nodes that do not implement the complete IEEE 802.15.4
     functionality, and is mainly targeted for constrained nodes with a
--- 546,555 ----
     the de-facto choice for a wide range of constrained node network
     application domains and has been a primary target technology of
     various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775],
!    [RFC4944], and 6TiSCH [I-D.ietf-6tisch-architecture].  IEEE 802.15.4
     specifies a variety of related PHY and MAC layer functionalites.

!    IEEE 802.15.4 defines three roles called device, coordinator, and
     Personal Area Network (PAN) coordinator.  The device role is adequate
     for nodes that do not implement the complete IEEE 802.15.4
     functionality, and is mainly targeted for constrained nodes with a
***************
*** 563,569 ****


     capabilities and is suitable for nodes that do not suffer severe
!    constraints (e.g. a mains-powered node).  The PAN coordinator is a
     special type of coordinator that acts as a principal controller in an
     IEEE 802.15.4 network.

--- 563,569 ----


     capabilities and is suitable for nodes that do not suffer severe
!    constraints (e.g., a mains-powered node).  The PAN coordinator is a
     special type of coordinator that acts as a principal controller in an
     IEEE 802.15.4 network.

***************
*** 571,583 ****
     configuration: beacon-enabled and nonbeacon-enabled networks.  In the
     first network type, coordinators periodically transmit beacons.  The
     time between beacons is divided in three main parts: the Contention
!    Access Period (CAP), the Contention Free Period (CFP) and an inactive
     period.  In the first period, nodes use slotted Carrier Sense
     Multiple Access / Collision Avoidance (CSMA/CA) for data
     communication.  In the second one, a TDMA scheme controls medium
     access.  During the idle period, communication does not take place,
!    thus the inactive period is a good opportunity for nodes to turn the
!    radio off and save energy.  The coordinator announces in each beacon
     the list of nodes for which data will be sent in the subsequent
     period.  Therefore, devices may remain in sleep mode by default and
     wake up periodically to listen to the beacons sent by their
--- 571,583 ----
     configuration: beacon-enabled and nonbeacon-enabled networks.  In the
     first network type, coordinators periodically transmit beacons.  The
     time between beacons is divided in three main parts: the Contention
!    Access Period (CAP), the Contention Free Period (CFP), and an inactive
     period.  In the first period, nodes use slotted Carrier Sense
     Multiple Access / Collision Avoidance (CSMA/CA) for data
     communication.  In the second one, a TDMA scheme controls medium
     access.  During the idle period, communication does not take place,
!    thus the inactive period is a good opportunity for nodes to turn their
!    radios off and save energy.  The coordinator announces in each beacon
     the list of nodes for which data will be sent in the subsequent
     period.  Therefore, devices may remain in sleep mode by default and
     wake up periodically to listen to the beacons sent by their
***************
*** 589,595 ****
     the message.

     The beacon interval and the duration of the beacon interval active
!    portion (i.e. the CAP and the CFP), and thus the duty cycle, can be
     configured.  The parameters that control these times are called
     macBeaconOrder and macSuperframeOrder, respectively.  As an example,
     when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be
--- 589,595 ----
     the message.

     The beacon interval and the duration of the beacon interval active
!    portion (i.e., the CAP and the CFP), and thus the duty cycle, can be
     configured.  The parameters that control these times are called
     macBeaconOrder and macSuperframeOrder, respectively.  As an example,
     when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be
***************
*** 598,604 ****

     In the beaconless mode, nodes use unslotted CSMA/CA for data
     transmission.  The device may be in sleep mode by default and may
!    activate its radio to either i) request to the coordinator whether
     there is pending data for the device, or ii) to transmit data to the
     coordinator.  The wake-up pattern of the device, if any, is out of
     the scope of IEEE 802.15.4.
--- 598,604 ----

     In the beaconless mode, nodes use unslotted CSMA/CA for data
     transmission.  The device may be in sleep mode by default and may
!    activate its radio to either i) to query the coordinator whether
     there is pending data for the device, or ii) to transmit data to the
     coordinator.  The wake-up pattern of the device, if any, is out of
     the scope of IEEE 802.15.4.
***************
*** 631,640 ****
     schedule whereby a set of time slots are used for frame transmission
     and reception, and other time slots are unscheduled.  The latter time
     slots may be used by a dynamic scheduling mechanism, otherwise nodes
!    may keep the radio off during the unscheduled time slots, thus saving
     energy.  The minimal schedule configuration specified in
     [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time
!    slots are unscheduled and the time slot duration is 15 ms.

     The previously mentioned CSL and RIT are also 802.15.4e modes
     designed for low energy.
--- 631,640 ----
     schedule whereby a set of time slots are used for frame transmission
     and reception, and other time slots are unscheduled.  The latter time
     slots may be used by a dynamic scheduling mechanism, otherwise nodes
!    may keep their radios off during the unscheduled time slots, thus saving
     energy.  The minimal schedule configuration specified in
     [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time
!    slots are unscheduled. The time slot duration is 15 ms.

     The previously mentioned CSL and RIT are also 802.15.4e modes
     designed for low energy.
***************
*** 648,654 ****
     operate on special power optimized silicon, but can connect to a DECT
     Gateway supporting traditional DECT / CAT-iq for cordless telephony
     and data as well as the DECT ULE extensions.  IPv6 can be run over
!    DECT ULE by using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule].

     DECT defines two major roles: the Portable Part (PP) is the power
     constrained device, while the Fixed Part (FP) is the Gateway or base
--- 648,654 ----
     operate on special power optimized silicon, but can connect to a DECT
     Gateway supporting traditional DECT / CAT-iq for cordless telephony
     and data as well as the DECT ULE extensions.  IPv6 can be run over
!    DECT ULE using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule].

     DECT defines two major roles: the Portable Part (PP) is the power
     constrained device, while the Fixed Part (FP) is the Gateway or base
***************
*** 656,666 ****
     reserved frequency bands based on TDMA/FDMA and TDD using dynamic
     channel allocation for interference avoidance.  It provides good
     indoor (~50 m) and outdoor (~300 m) coverage.  It uses a frame length
!    of 10 ms divided into 24 timeslots, and it supports connection
!    oriented, packet data and connection-less services.

     The FP usually transmits a so-called dummy bearer (beacon) that is
!    used to broadcast synchronization, system and paging information.
     The slot/carrier position of this dummy bearer can automatically be
     reallocated in order to avoid mutual interference with other DECT
     signals.
--- 656,666 ----
     reserved frequency bands based on TDMA/FDMA and TDD using dynamic
     channel allocation for interference avoidance.  It provides good
     indoor (~50 m) and outdoor (~300 m) coverage.  It uses a frame length
!    of 10 ms divided into 24 timeslots. It supports connection
!    oriented, packet data, and connection-less services.

     The FP usually transmits a so-called dummy bearer (beacon) that is
!    used to broadcast synchronization, system, and paging information.
     The slot/carrier position of this dummy bearer can automatically be
     reallocated in order to avoid mutual interference with other DECT
     signals.
***************
*** 674,705 ****
  Internet-Draft            Lwig Energy Efficient             October 2017


!    At the MAC level DECT ULE communications between FP and PP are
!    initiated by the PP.  A FP can initiate communication indirectly by
     sending paging signal to a PP.  The PP determines the timeslot and
!    frequency on which the communication between FP and PP takes place.
     The PP verifies the radio timeslot/frequency position is unoccupied
     before it initiates its transmitter.  An access-request message,
     which usually carries data, is sent to the FP.  The FP sends a
     confirm message, which also may carry data.  More data can be sent in
     subsequent frames.  A MAC level automatic retransmission scheme
     significantly improves data transfer reliability.  A segmentation and
!    reassembly scheme supports transfer of larger higher layer SDUs and
     provides data integrity check.  The DECT ULE packet data service
     ensures data integrity, proper sequencing, duplicate protection, but
!    not guaranteed delivery.  Higher layers protocols have to take this
     into consideration.

     The FP may send paging information to PPs to trigger connection setup
!    and indicate the required service type.  The interval between paging
     information to a specific PP can be defined in range 10 ms to 327
     seconds.  The PP may enter sleep mode to save power.  The listening
     interval is defined by the PP application.  For short sleep intervals
!    (below ~10 seconds) the PP may be able to retain synchronization to
!    the FP dummy bearer and only turn on the receiver during the expected
!    timeslot.  For longer sleep intervals the PP can't keep
     synchronization and has to search for and resynchronize to the FP
!    dummybearer.  Hence, longer sleep interval reduces the average energy
     consumption, but adds a energy consumption penalty for acquiring
     synchronization to the FP dummy bearer.  The PP can obtain all
     information to determine paging and acquire synchronization
--- 674,705 ----
  Internet-Draft            Lwig Energy Efficient             October 2017


!    At the MAC level, DECT ULE communications between FP and PP are
!    initiated by the PP.  An FP can initiate communication indirectly by
     sending paging signal to a PP.  The PP determines the timeslot and
!    frequency at which communication between the FP and PP takes place.
     The PP verifies the radio timeslot/frequency position is unoccupied
     before it initiates its transmitter.  An access-request message,
     which usually carries data, is sent to the FP.  The FP sends a
     confirm message, which also may carry data.  More data can be sent in
     subsequent frames.  A MAC level automatic retransmission scheme
     significantly improves data transfer reliability.  A segmentation and
!    reassembly scheme supports transfer of larger higher-layer SDUs and
     provides data integrity check.  The DECT ULE packet data service
     ensures data integrity, proper sequencing, duplicate protection, but
!    not guaranteed delivery.  Higher-layer protocols have to take this
     into consideration.

     The FP may send paging information to PPs to trigger connection setup
!    and indicate the required service type.  The interval between sending paging
     information to a specific PP can be defined in range 10 ms to 327
     seconds.  The PP may enter sleep mode to save power.  The listening
     interval is defined by the PP application.  For short sleep intervals
!    (below ~10 seconds), the PP may be able to retain synchronization to
!    the FP dummy bearer and only turn on its receiver during the expected
!    timeslot.  For longer sleep intervals, the PP can't keep
     synchronization and has to search for and resynchronize to the FP
!    dummy bearer.  Hence, longer sleep interval reduces the average energy
     consumption, but adds a energy consumption penalty for acquiring
     synchronization to the FP dummy bearer.  The PP can obtain all
     information to determine paging and acquire synchronization
***************
*** 711,724 ****
     about 10 ms by doing energy consuming RSSI scanning in advance.  In
     the direction from FP to PP the latency is usually increased by the
     used paging interval and the sleep interval.  The MAC layer can
!    piggyback commands to improve efficiency (reduce latency) of higher
     layer protocols.  Such commands can instruct the PP to initiate a new
     packet transfer in N frames without the need for resynchronization
     and listening to paging or instruct the PP to stay in a higher duty
     cycle paging detection mode.

     The DECT ULE technology allows per PP configuration of paging
!    interval, MTU size, reassembly window size and higher layer service
     negotiation and protocol.


--- 711,724 ----
     about 10 ms by doing energy consuming RSSI scanning in advance.  In
     the direction from FP to PP the latency is usually increased by the
     used paging interval and the sleep interval.  The MAC layer can
!    piggyback commands to improve efficiency (reduce latency) of higher-
     layer protocols.  Such commands can instruct the PP to initiate a new
     packet transfer in N frames without the need for resynchronization
     and listening to paging or instruct the PP to stay in a higher duty
     cycle paging detection mode.

     The DECT ULE technology allows per PP configuration of paging
!    interval, MTU size, reassembly window size, and higher-layer service
     negotiation and protocol.


***************
*** 736,742 ****
     IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three
     aspects, as follows.

!    First, 6LoWPAN provides one fragmentation and reassembly mechanism
     which is aimed at solving the packet size issue in IPv6 and could
     also affect energy-efficiency.  IPv6 requires that every link in the
     internet have an MTU of 1280 octets or greater.  On any link that
--- 736,742 ----
     IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three
     aspects, as follows.

!    First, 6LoWPAN provides a fragmentation and reassembly mechanism
     which is aimed at solving the packet size issue in IPv6 and could
     also affect energy-efficiency.  IPv6 requires that every link in the
     internet have an MTU of 1280 octets or greater.  On any link that
***************
*** 749,765 ****
     the IP layer will produce more IP packets, each one carrying its own
     IP header.  However, performance can be severely affected if, after
     IP layer fragmentation, then 6LoWPAN fragmentation happens as well
!    (e.g. when the upper layer is not aware of the existence of the
     fragmentation at the 6LoWPAN layer).  One solution is to require
!    higher layers awareness of lower layer features and generate small
     enough packets to avoid fragmentation.  In this regard, the Block
     option in CoAP can be useful when CoAP is used at the application
     layer [RFC 7959].

     Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies
     compression of the IPv6 header.  Subject to the packet size limit of
!    IEEE 802.15.4, 40 octets long IPv6 header and 8 octets or 20 octets
!    long UDP and TCP header will consume even more packet space than the
     data itself. 6LoWPAN provides IPv6 and UDP header compression at the
     adaptation layer.  Therefore, a lower amount of data will be handled
     by the lower layers, whereas both the sender and receiver will spend
--- 749,765 ----
     the IP layer will produce more IP packets, each one carrying its own
     IP header.  However, performance can be severely affected if, after
     IP layer fragmentation, then 6LoWPAN fragmentation happens as well
!    (e.g., when the upper layer is not aware of the existence of the
     fragmentation at the 6LoWPAN layer).  One solution is to require
!    higher-layer awareness of lower-layer features and generate small
     enough packets to avoid fragmentation.  In this regard, the Block
     option in CoAP can be useful when CoAP is used at the application
     layer [RFC 7959].

     Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies
     compression of the IPv6 header.  Subject to the packet size limit of
!    IEEE 802.15.4, a 40-octets IPv6 header and an 8-octet or 20-octet
!    UDP or TCP header will consume even more packet space than the
     data itself. 6LoWPAN provides IPv6 and UDP header compression at the
     adaptation layer.  Therefore, a lower amount of data will be handled
     by the lower layers, whereas both the sender and receiver will spend
***************
*** 788,807 ****

     one second apart).  NUD timeout settings should be tuned taking into
     account the latency that may be introduced by duty-cycled mechanisms
!    at the link layer, or alternative, less impatient NUD algorithms
     should be considered [I-D.ietf-6man-impatient-nud].

!    IPv6 underlies the higher layer protocols, including both TCP/UDP
     transport and applications.  By design, the higher-layer protocols do
     not typically have specific information about the lower layers, and
     thus cannot solve the energy-efficiency problem.

     The network stack can be designed to save computing power.  For
!    example the Contiki implementation has multiple cross layer
     optimizations for buffers and energy management, e.g., the computing
     and validation of UDP/TCP checksums without the need of reading IP
     headers from a different layer.  These optimizations are software
!    implementation techniques, and out of the scope of IETF and the LWIG
     working group.

  5.  Routing Protocols
--- 788,807 ----

     one second apart).  NUD timeout settings should be tuned taking into
     account the latency that may be introduced by duty-cycled mechanisms
!    at the link layer, or as an alternative, less impatient NUD algorithms
     should be considered [I-D.ietf-6man-impatient-nud].

!    IPv6 underlies the higher-layer protocols, including both TCP/UDP
     transport and applications.  By design, the higher-layer protocols do
     not typically have specific information about the lower layers, and
     thus cannot solve the energy-efficiency problem.

     The network stack can be designed to save computing power.  For
!    example, the Contiki implementation has multiple cross-layer
     optimizations for buffers and energy management, e.g., the computing
     and validation of UDP/TCP checksums without the need of reading IP
     headers from a different layer.  These optimizations are software
!    implementation techniques, and out of the scope of the IETF and the LWIG
     working group.

  5.  Routing Protocols
***************
*** 816,836 ****
     The authors of the Powertrace tool [Powertrace] studied the power
     profile of RPL.  Their analysis divides the routing protocol into
     control and data traffic.  The control plane carries ICMP messages to
!    establish and maintain the routing states.  The data plane carries
     any application that uses RPL for routing packets.  The study has
!    shown that the power consumption of the control traffic goes down
!    over time in a relatively stable network.  The study also reflects
     that the routing protocol should keep the control traffic as low as
     possible to make it energy-friendly.  The amount of RPL control
     traffic can be tuned by setting the Trickle [RFC6206] algorithm
!    parameters (i.e.  Imin, Imax and k) to appropriate values.  However,
     there exists a trade-off between energy consumption and other
     performance parameters such as network convergence time and
     robustness.

     RFC 6551 [RFC6551] defines routing metrics and constraints to be used
     by RPL in route computation.  Among others, RFC 6551 specifies a Node
!    Energy object that allows to provide information related to node
     energy, such as the energy source type or the estimated percentage of
     remaining energy.  Appropriate use of energy-based routing metrics

--- 816,836 ----
     The authors of the Powertrace tool [Powertrace] studied the power
     profile of RPL.  Their analysis divides the routing protocol into
     control and data traffic.  The control plane carries ICMP messages to
!    establish and maintain routing states.  The data plane carries
     any application that uses RPL for routing packets.  The study has
!    shown that the power consumption of control traffic goes down
!    over time in a relatively stable network.  The study also recommends
     that the routing protocol should keep the control traffic as low as
     possible to make it energy-friendly.  The amount of RPL control
     traffic can be tuned by setting the Trickle [RFC6206] algorithm
!    parameters (i.e., Imin, Imax, and k) to appropriate values.  However,
     there exists a trade-off between energy consumption and other
     performance parameters such as network convergence time and
     robustness.

     RFC 6551 [RFC6551] defines routing metrics and constraints to be used
     by RPL in route computation.  Among others, RFC 6551 specifies a Node
!    Energy object that provides information related to node
     energy, such as the energy source type or the estimated percentage of
     remaining energy.  Appropriate use of energy-based routing metrics

***************
*** 843,849 ****


     may help to balance energy consumption of network nodes, minimize
!    network partitioning and increase network lifetime.

  6.  Application Layer

--- 843,849 ----


     may help to balance energy consumption of network nodes, minimize
!    network partitioning, and increase network lifetime.

  6.  Application Layer

***************
*** 856,869 ****
     binary header.

     Energy efficiency is part of the CoAP protocol design.  CoAP uses a
!    fixed-length binary header of only four bytes that may be followed by
     binary options.  To reduce regular and frequent queries of the
     resources, CoAP provides an observe mode, in which the requester
!    registers its interest of a certain resource and the responder will
!    report the value whenever it was updated.  This reduces the request
     response round trips while keeping information exchange a ubiquitous
     service; an energy-constrained server can remain in sleep mode during
!    the period between observe notification transmissions.

     Furthermore, [RFC7252] defines CoAP proxies which can cache resource
     representations previously provided by sleepy CoAP servers.  The
--- 856,869 ----
     binary header.

     Energy efficiency is part of the CoAP protocol design.  CoAP uses a
!    fixed-length binary header of only four octets that may be followed by
     binary options.  To reduce regular and frequent queries of the
     resources, CoAP provides an observe mode, in which the requester
!    registers its interest in a certain resource and the responder will
!    report the value whenever it was updated.  This reduces the request/
     response round trips while keeping information exchange a ubiquitous
     service; an energy-constrained server can remain in sleep mode during
!    the period between observe-notification transmissions.

     Furthermore, [RFC7252] defines CoAP proxies which can cache resource
     representations previously provided by sleepy CoAP servers.  The
***************
*** 874,887 ****

     CoAP proxy and cache functionality may also be used to perform data
     aggregation.  This technique allows a node to receive data messages
!    (e.g. carrying sensor readings) from other nodes in the network,
     perform an operation based on the content in those messages, and
     transmit the result of the operation.  Such operation may simply be
     intended to use one packet to carry the readings transported in
     several packets (which reduces header and transmission overhead), or
     it may be a more sophisticated operation, possibly based on
!    mathematical, logical or filtering principles (which reduces the
!    payload size to be transmitted).

  6.2.  Sleepy node support

--- 874,887 ----

     CoAP proxy and cache functionality may also be used to perform data
     aggregation.  This technique allows a node to receive data messages
!    (e.g., carrying sensor readings) from other nodes in the network,
     perform an operation based on the content in those messages, and
     transmit the result of the operation.  Such operation may simply be
     intended to use one packet to carry the readings transported in
     several packets (which reduces header and transmission overhead), or
     it may be a more sophisticated operation, possibly based on
!    mathematical, logical, or filtering principles (which reduces the
!    transmitted payload size).

  6.2.  Sleepy node support

***************
*** 898,911 ****
  Internet-Draft            Lwig Energy Efficient             October 2017


!    mechanisms) in a scenario with sleepy devices has been described
     [I-D.ietf-lwig-crypto-sensors].  Approaches to support sleepy nodes
     include exploiting the use of proxies, leveraging the Resource
!    Directory [I-D.ietf-core-resource-directory] or signaling when a node
     is awake to the interested nodes.  Recent work defines publish-
     subscribe and message queuing extensions to CoAP and the Resource
     Directory in order to support devices that spend most of their time
!    in asleep [I-D.ietf-core-coap-pubsub].  Notably, this work has been
     adopted by the CoRE Working Group.

     In addition to the work within the scope of CoAP to support sleepy
--- 898,911 ----
  Internet-Draft            Lwig Energy Efficient             October 2017


!    mechanisms) in a scenario with sleepy devices has been described in
     [I-D.ietf-lwig-crypto-sensors].  Approaches to support sleepy nodes
     include exploiting the use of proxies, leveraging the Resource
!    Directory [I-D.ietf-core-resource-directory], or signaling when a node
     is awake to the interested nodes.  Recent work defines publish-
     subscribe and message queuing extensions to CoAP and the Resource
     Directory in order to support devices that spend most of their time
!    asleep [I-D.ietf-core-coap-pubsub].  Notably, this work has been
     adopted by the CoRE Working Group.

     In addition to the work within the scope of CoAP to support sleepy
***************
*** 929,939 ****
     RTO value is chosen randomly between 2 and 3 s.  If an RTO expires,
     the new RTO value is doubled (unless a limit on the number of
     retransmissions has been reached).  Since duty-cycling at the link
!    layer may lead to long latency (i.e. even greater than the initial
     RTO value), CoAP RTO parameters should be tuned accordingly in order
     to avoid spurious RTOs which would unnecessarily waste node energy
     and other resources.  On the other hand, note that CoAP can also run
!    on top of TCP [I-D.ietf-core-coap-tcp-tls].  In that case, similar
     guidance applies to TCP timers, albeit with greater motivation to
     carefully configure TCP RTO parameters, since [RFC6298] reduced the
     default initial TCP RTO to 1 second, which may interact more
--- 929,939 ----
     RTO value is chosen randomly between 2 and 3 s.  If an RTO expires,
     the new RTO value is doubled (unless a limit on the number of
     retransmissions has been reached).  Since duty-cycling at the link
!    layer may lead to long latency (i.e., even greater than the initial
     RTO value), CoAP RTO parameters should be tuned accordingly in order
     to avoid spurious RTOs which would unnecessarily waste node energy
     and other resources.  On the other hand, note that CoAP can also run
!    on top of TCP [I-D.ietf-core-coap-tcp-tls].  In this case, similar
     guidance applies to TCP timers, albeit with greater motivation to
     carefully configure TCP RTO parameters, since [RFC6298] reduced the
     default initial TCP RTO to 1 second, which may interact more
***************
*** 943,949 ****

     Another method intended to reduce the size of the data units to be
     communicated in constrained-node networks is data compression, which
!    allows to encode data using less bits than the original data
     representation.  Data compression is more efficient at higher layers,
     particularly before encryption is used.  In fact, encryption

--- 943,949 ----

     Another method intended to reduce the size of the data units to be
     communicated in constrained-node networks is data compression, which
!    allows encoding data using less bits than the original data
     representation.  Data compression is more efficient at higher layers,
     particularly before encryption is used.  In fact, encryption

***************
*** 969,979 ****
         reduce power consumption, it is recommended that Layer 3 designs
         should operate based on awareness of lower-level parameters
         rather than treating the lower layer as a black box (Sections 4,
!        5 and 6).

     b.  It is always useful to compress the protocol headers in order to
         reduce the transmission/reception power.  This design principle
!        has been employed by many protocols in 6Lo and CoRE working group
         (Sections 4 and 6).

     c.  Broadcast and non-synchronized transmissions consume more than
--- 969,979 ----
         reduce power consumption, it is recommended that Layer 3 designs
         should operate based on awareness of lower-level parameters
         rather than treating the lower layer as a black box (Sections 4,
!        5, and 6).

     b.  It is always useful to compress the protocol headers in order to
         reduce the transmission/reception power.  This design principle
!        has been employed by many protocols in the 6Lo and CoRE working group
         (Sections 4 and 6).

     c.  Broadcast and non-synchronized transmissions consume more than

Thanks,
Acee