Subject: [manet-dlep-rg] First milestone, next steps

From: Teco Boot <[email-masked]>
Date: Mon, 4 Nov 2013 17:52:09 +0100

Op 3 sep. 2013, om 11:20 heeft Teco Boot <[email-masked]> het volgende geschreven:

(skipped)

> All:
> I think we achieved out first milestones. Maybe define our next steps. Make list of what we have? Then define what the core/optional metrics would be? Define handling "order"? Discussion of flow control and how to deal with multiple queues in the radio and multi-hop L2 links?

To make up _my_ mind on where we are and what next steps we could made, I went thru dlep-04 and the outcome of our work. Below my notes.

Teco

9.1  DLEP Version  . . . . . . . . . . . . . . . . . . . . . . . 14
     Peer, optional.
     No text on conflict handling.  
     No text on what version is used if no DLEP version is sent.

9.2  Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 15
     Peer, optional.
     Can be used to identify peer.
     Suggestion: 
      - make it mandatory
      - split into subtypes, such as manufacturer, model, revision 
         and serial number?
      - enable for neighbor
     3GPP command: AT+CGMI;+CGMM;+CGMR;+CGSN
  
9.3  MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 15
     Neighbor, mandatory.
     Text says: "remote node". This is not an exact specification,
     remote node has at least two MAC addresses, maybe more. One of 
     the MAC addresses is selected as NeighborMacAddress. As routers
     can be disconnected and reconnected to another modem, and DLEP
     is about the modem link, I suggest to specify it MUST be the
     modem MAC address and used as NeighborID. Additional router or
     modem MAC addresses may be added and deleted with same mechanism 
     as IP addresses. These addresses are optional and to be used for 
     user traffic.

9.4  IPv4 Address  . . . . . . . . . . . . . . . . . . . . . . . 16
     Peer and Neighbor, optional.
     Text not clear on "neighbor". Could be remote modem or remote
     router. This is risky, if address is used for routing protocol
     neighbor up/down, and an IP address is removed from remote modem,
     connectivity would be lost.
     Remote access on IP layer to remote modems is important (management
     from NOC).
     "Subnet mask" is obsolete and incorrect. Masks have same length as 
     address and can have any bit pattern. 
     Because there is a prefix length, the TLV should be renamed to 
     Prefix. 

9.5  IPv6 Address  . . . . . . . . . . . . . . . . . . . . . . . 17
     As 9.4 IPv4 address.

9.6  Maximum Data Rate (Receive) . . . . . . . . . . . . . . . . 17
     Peer and Neighbor, mandatory but "0" for unknown.
     When peer and neighbor MDR (R&T) are not equal, is lowest value
     used? Lowest from (neighbor MDRR, peer MGRT) and (neighbor MDRT, 
     peer MGRR)?

9.7  Maximum Data Rate (Transmit)  . . . . . . . . . . . . . . . 18
     As 9.6 MDRR.
     Why differs text on "0" for unknown?

9.8  Current Data Rate (Receive) . . . . . . . . . . . . . . . . 19
     Peer and Neighbor, mandatory.
     What is TLV Flags?
     For Peer Discovery and Peer Update, CDR cannot be provided and is 
     useless becasue it is overridden by each and every neighbor.
     In previous DLEP-RG discussions, the outcome was that CDR was the
     data rate when a single node sends or receives on an idle medium. 
     In a shared medium, actual DR would be less than CDR.
     It is unclear if CDR is modulation rate or includes sub-layers
     overhead. If sub-layer overhead is included, what is the packet 
     length for the provided CDR?
   - For 3GPP modems, there is no defined API getting CDR. So having 
     this TLV mandatory, modems are forced to lie or provide a best 
     guess based on other information. The best guess could be based on 
     radio technology (AT*CNTI=0) and signal quality (AT+CSQ and radio
     technology specific commands).
   - For 802.11 modems: Rx bitrate (bit/s)
   - Mesh: can be provided, but sometimes for last leg in L2-path
     
9.9  Current Data Rate (Transmit)  . . . . . . . . . . . . . . . 20
     As 9.8 CDRR. 
   - For 802.11 modems: Tx bitrate (bit/s)
   - Mesh: can be provided, but sometimes for first leg in L2-path

9.10  Expected Forwarding Time . . . . . . . . . . . . . . . . . 21
      Peer and Neighbor, optional.
      For peer messages: as 9.8 CDRR.
      Difference with 9.11 latency is unclear. The text says it is 
      latency, so probably there is no difference.
      In the description, travelling time is missing (on satcom systems 
      this can be huge). Why not 64-bit and microseconds?
      Shouldn't this metric be specified for transmit and receive?
      
9.11  Latency  . . . . . . . . . . . . . . . . . . . . . . . . . 21
      As 9.10 EFT.
    - Mesh: latency.

9.12  Resources (Receive)  . . . . . . . . . . . . . . . . . . . 22
      Peer and Neighbor, optional, with "0" for unknown.
      Question remains how to use this TLV. 
      For battery level, transmit and receive would have same battery, 
      so same level. 

9.13  Resources (Transmit) . . . . . . . . . . . . . . . . . . . 22
      As 9.12 RsrcR.

9.14  Relative Link Quality (Receive)  . . . . . . . . . . . . . 23
      Peer and Neighbor, optional, with "0" for unknown.
      What is the meaning of peer RLQ?
      TLV is known as RSSI, although definitions on link signal strength 
      and signal quality vary a lot.
      Most often, this metric is measured at receiver.
    - 3GPP command for RSSI: AT+CSQ
    - 802.11: combination of Rx Signal strength, Rx Signal to 
      Interference and Noise Ratio and Rx biterror rate.
    - Milradio: RSSI  
    - Satcom modems use Eb/No for this.  

9.15  Relative Link Quality (Transmit) . . . . . . . . . . . . . 24
      As 9.14 RsrcT.

9.16  Status . . . . . . . . . . . . . . . . . . . . . . . . . . 24
      No comments now.

9.17  Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 25
      To be updated with TCP.

9.18  Link Characteristics ACK Timer . . . . . . . . . . . . . . 26
      To be updated with TCP. 
      Default timer shall be specified.
      Max timer could be dependent of requested operation.
      maybe replace with a "Command received, wait for n ms" response, 
      repeated at 1/3 of timer?
      3GPP commands: many: call setup and hangup, QoS setup.

9.19  Credit Window Status . . . . . . . . . . . . . . . . . . . 26
      Neighbor, optional.
      Add text (in 9.19) that credits are in octets.
      Why would a router have a Receive Window?
      Credits should be for QoS classes.
      Add facility for multicast and broadcast credits.
 
9.20  Credit Grant Request . . . . . . . . . . . . . . . . . . . 27
      Neighbor, optional.
      So each MRW is followed by CWS from router to modem and CWS
      from radio to router? Both with timers and retransmit?
      Discussion on missing seqno. Or is exchange using stop_wait until 
      complete before a next CGR? If stop_wait is used, CWS for WRW and
      RRW cannot be combined in single message.
      Is credit a window or counter? 64-bit field for window is huge.

9.21  Credit Request . . . . . . . . . . . . . . . . . . . . . . 28
      Neighbor, optional.
      When 1-octed TLV is used, Length is 1. Skip unused field?

In general:
      The discussion on support for multicast/broadcast had an outcome
      that neighbor multicast/broadcast addresses can be used. Add this 
      in the document?

===========
      
Not in document:
3GPP:
  Network technology
  Received signal code power 
  Total Energy per chip per power density
  Average WCDMA power level over time period
  (LTE stuff)
  Packet Data Protocol (PDP) context functions (QoS)

802.11:
  Network identifier (ascii string)
  Supported bitrates (array in bit/s)
  Bandwidth (Hz)
  Channel active time (ms)
  Channel busy time (ms)
  Channel receive time (ms)
  Channel transmit time (ms)
  Channel utilization (dimensionless 0-100)
  Frequency (Hz)
  Transmission power (dBm)
  Last active (ms)
  Link Status (heard, silent, symmetric, lost)
  Rx frames (dimensionless)
  Rx loss (dimensionless)
  Tx frames (dimensionless)
  Tx loss (dimensionless)
  Tx retries (dimensionless)
  Expected Transmission Time (ms)
  Power constraint (dBm)
  Rx Signal strength (dBm)
  Rx Signal to Interference and Noise Ratio (dB)
  Rx biterror rate (dimensionless, 10^0 to 10^-15 ?)

Milradio:
  Radio identifier
  GPS location
  FEC mode
  Modulation scheme
  Tx power
  Crypto mode
  Hopping mode
  
L2 mesh:
  hopcount (?)
  QoS facilities
  multiple paths

Discussed in face to face meeting:
  Shared available data rate (similar to 802.11 channel utilisation)

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 4 Nov 2013 18:11:47 +0000

Teco, 

On Nov 4, 2013, at 11:52 AM, Teco Boot <[email-masked]>
 wrote:

>> I think we achieved out first milestones.

On this, I disagree. We had a charter that said we'd research existing radio types, and come up with a set of common metrics that were applicable across those radios. We did the research, but then things sort of "fell off the side of the cliff" - not a lot happened afterward. I'll take my fair share of the blame - things at work just got too busy. 

But, IMO, the design team report to the WG needs to start out with a slide that says "We Blew It - We had a deadline, and we missed it." Then we can talk about next steps. 

Regards,
Stan

>> Maybe define our next steps. Make list of what we have? Then define what the core/optional metrics would be? Define handling "order"? Discussion of flow control and how to deal with multiple queues in the radio and multi-hop L2 links?
> 
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: Teco Boot <[email-masked]>
Date: Mon, 4 Nov 2013 20:30:49 +0100

Stan,

Rick started a thread on next milestones, IMHO within our charter. First four milestones were research existing radio types, we finished that part. So now we come up with a set of common metrics, that would be a next milestone. The QoS specific stuff is another milestone. Do I miss something? Were deadlines set on the next milestones?

We still can catch 9/15 2014 :-). Let’s have good discussions tomorrow and report something useful on Thursday. I’m optimistic.

Teco