Subject: [manet] DLEP 09 Credit-Windowing

From: "Goff, Thomas" <[email-masked]>
Date: Wed, 6 May 2015 00:36:45 +0000

All,

I wonder if it would make sense to consider some possible changes to the current DLEP credit-windowing specification, specifically:

 - Use absolute credits by advertising a current receive window rather than granting incremental credits.  This would avoid having to handle synchronization and overflow issues and in some cases might improve adapting to degraded link conditions (a modem could immediately shrink its window instead of waiting for the peer to run out of all previously granted credits).

 - Support the use of unidirectional credit-windowing where each DLEP participant can decided if credits should be used for data it receives (on a per-destination basis).  My understanding is that credit-windowing and flow control is not needed for traffic flowing from the modem to a router in most use cases.

I also think it would be helpful if DLEP described how credit accounting should be performed.  For example, say credits apply to layer 2 frames sent between the router and modem.

A possible modified section 8 based on draft-ietf-manet-dlep-09 is included below.

  Tom

8.  Credit-Windowing

   DLEP includes an OPTIONAL Protocol Extension for a credit-windowing
   scheme analogous to the one documented in [RFC5578].  In this scheme,
   per-destination traffic between the router and modem is treated as two
   unidirectional flows.  When credit-windowing is supported by the DLEP
   session, each DLEP participant (modem and router) independently
   controls if credit-windowing will be used when receiving data
   associated with a destination.

   Credits are managed independently in each direction on a
   destination-specific basis; that is, separate credit counts are
   maintained for each destination requiring the service.  Credits do not
   apply to the DLEP session that exists between routers and modems.

   If the OPTIONAL credit-windowing extension is used, a DLEP participant
   advertises a current Receive Window to inform its peer how much data
   it can receive to/from the associated destination, in bytes.  Credit
   accounting is performed based on the Layer 2 frames sent between DLEP
   peers.  For Ethernet this includes the Ethernet header, payload, and
   frame check sequence.

   When unidirectional credit-windowing is used, a DLEP participant
   SHOULD NOT forward data for the associated destination unless the
   current Receive Window of its DLEP peer has sufficient credits, in
   bytes.  The length of each associated Layer 2 frame SHOULD be deducted
   from the peer's current Receive Window after being forwarded.  A
   peer's destination-specific current Receive Window SHOULD be set to
   the advertised value when a Credit Window Status data item is
   received.

   If a peer is able to support the OPTIONAL credit-windowing extension
   then it MUST include a Extensions Supported data item (Section 7.7)
   including the value DLEP_EXT_CREDITS (value TBD) in the appropriate
   Peer Initialization or Peer Initialization ACK signal.

8.1.  Credit-Windowing Signals

   The credit-windowing extension introduces no additional DLEP signals.
   However, if a peer has advertised during session initialization that
   it supports the credit-windowing extension then the following DLEP
   signals MAY contain additional credit-windowing data items:

8.1.1.  Destination Up Signal

   The Destination Up signal MAY contain one of each of the following
   data items:

   o  Credit Window Status (Section 8.2.1)

   The use of unidirectional credits is enabled when the Destination Up
   signal includes a Credit Window Status data item.  In this case,
   destination-specific credit-windowing MUST be performed for traffic
   sent to the associated destination flowing toward the originator of
   the Destination Up signal.

   If the Destination Up signal does not contain the Credit Window Status
   data item, unidirectional credits MUST NOT be used for that
   destination.

8.1.2.  Destination Up ACK Signal

   The Destination Up ACK signal MAY contain one of each of the
   following data items:

   o  Credit Window Status (Section 8.2.1)

   The use of unidirectional credits is enabled if the Destination Up ACK
   signal includes a Credit Window Status data item.  In this case,
   destination-specific credit-windowing MUST be performed for traffic
   sent from the associated destination when the destination is physical
   (unicast), or to the associated destination when the destination is
   logical (multicast or broadcast), flowing toward the originator of the
   Destination Up ACK signal.

   If the Destination Up ACK signal does not contain the Credit Window
   Status data item, unidirectional credits MUST NOT be used for that
   destination.

8.1.3.  Destination Update Signal

   If the originator's corresponding Destination Up or Destination Up ACK
   signal contained the Credit Window Status data item, the Destination
   Update signal MUST contain one of each of the following data items:

   o  Credit Window Status (Section 8.2.2)

   If the recipient's (i.e., the DLEP peer's) corresponding Destination
   Up or Destination Up ACK signal contained the Credit Window Status
   data item, the Destination Update signal MAY contain one of each of
   the following data items:

   o  Credit Request (Section 8.2.2)

8.2.  Credit-Windowing Data Items

   The credit-windowing extension introduces 2 additional data items.
   If a peer has advertised during session initialization that it
   supports the credit-windowing extension then it MUST correctly
   process the following data items without error.

          +------------+-----------------------+----------------+
          | Data Item  | Description           | Section        |
          +------------+-----------------------+----------------+
          | TBD        | Credit Window Status  | Section 8.2.1  |
          | TBD        | Credit Request        | Section 8.2.2  |
          +------------+-----------------------+----------------+

8.2.1.  Credit Window Status

   The Credit Window Status data item is sent by a DLEP participant to
   indicate the current amount of data that can be received for a given
   destination, in bytes.

   If the credit-window extension is supported by the DLEP participants
   (both the router and the modem), the Credit Window Status data item
   MAY be included in the Destination Up or Destination Up ACK signal to
   enable unidirectional credit-windowing for a given destination.
   Subsequent Destination Update signals MUST also contain the Credit
   Window Status data item if a DLEP participant enabled credit-windowing
   (by including a Credit Window Status data item in the initial
   Destination Up or Destination Up ACK signal).

   The Credit Window Status data item contains the following fields:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type|    Length     |     Receive Window Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Receive Window Value                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Receive Window Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data Item Type:  TBD

   Length:  8

   Receive Window Value:  A 64-bit unsigned integer, indicating
      the current number of credits available on the sender's Receive
      Window, for the destination referred to by the signal.

8.2.2.  Credit Request

   If the use of unidirectional credits was enabled by the DLEP peer, the
   Credit Request data item MAY be sent from either DLEP participant, via
   the Destination Update signal (Section 6.13), to indicate the desire
   for additional credits from the partner in order for data transfer to
   proceed for the destination.

   If the recipient's corresponding Destination Up signal (Section 6.9)
   or Destination Up ACK signal (Section 6.10) included a Credit Window
   Status data item, the recipient SHOULD reply by sending a Destination
   Update signal that includes a Credit Window Status data item
   indicating the current number of credits that can be received for the
   given destination.

   The Credit Request data item MUST be silently ignored if the
   corresponding Destination Up signal or Destination Up ACK signal sent
   by the recipient did NOT contain a Credit Window Status data item.

   The Credit Request data item contains the following fields:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type|    Length     |
   |               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data Item Type:  TBD

   Length:  0