Subject: Re: [manet] DLEP 09 Credit-Windowing

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Wed, 6 May 2015 20:22:21 +0000

I read through draft 10.  Looks good.  Just fix the minor version as
Christopher pointed out.  Authors, thanks for all of your efforts to clean
it up.

Regarding this:

On 5/5/15, 8:36 PM, "Goff, Thomas" <[email-masked]> wrote:
>- 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 think this part is possible with the current draft.  The router will
still have to advertise support of the credit-windowing extension to
enable its peer to use credits because "an implementation MUST NOT emit
any signal or data item associated with an optional extension that was not
specified in the received initialization signal from its peer." (3.1)
However, whenever the router sends a Destination Up, it can simply omit
the Credit Grant data item.  "If the Destination Up signal does not
contain the Credit Grant data item, credits MUST NOT be used for that
destination." (9.1.1)  So it seems the use of flow control is already
controllable per destination.

If I have misunderstood something, please let me know.

David

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 6 May 2015 21:10:50 +0000

David, 

Your analysis of credit-window control by destination is spot-on. That was the intent. 

Regards,
Stan

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: Wednesday, May 06, 2015 4:22 PM
> To: Goff, Thomas; [email-masked]
> Subject: Re: [manet] DLEP 09 Credit-Windowing
> 
> I read through draft 10.  Looks good.  Just fix the minor version as Christopher
> pointed out.  Authors, thanks for all of your efforts to clean it up.
> 
> Regarding this:
> 
> >(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 think this part is possible with the current draft.  The router will still have to
> advertise support of the credit-windowing extension to enable its peer to
> use credits because "an implementation MUST NOT emit any signal or data
> item associated with an optional extension that was not specified in the
> received initialization signal from its peer." (3.1) However, whenever the
> router sends a Destination Up, it can simply omit the Credit Grant data item.
> "If the Destination Up signal does not contain the Credit Grant data item,
> credits MUST NOT be used for that destination." (9.1.1)  So it seems the use
> of flow control is already controllable per destination.
>

---

From: "Goff, Thomas" <[email-masked]>
Date: Wed, 6 May 2015 23:18:51 +0000

Just to clarify, by unidirectional credit-windowing I was referring to
credit granting by only one DLEP participant (e.g. the modem) for a
destination; the other participant (e.g. the router) would not grant
credits for that destination.  Is this supported by the current DLEP
credit-windowing approach?

My interpretation of section 9.2.1, specifically:

   If the initialization completes successfully, the receiver MUST
   respond to the Destination Up signal with a Destination Up ACK signal
   that contains a Credit Window Status data item, initializing its
   receive window.

is that the receiver is effectively granting initial credits by
"initializing its receive window".  At that point credit windowing is
active for the destination in both directions and each side is
responsible for granting credits on its receive window.  Is that a
misinterpretation?

  Tom

> From: Ratliff, Stanley [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 2:11 PM
> To: Wiggins, David - 0665 - MITLL; Goff, Thomas; [email-masked]
> Subject: RE: [manet] DLEP 09 Credit-Windowing
> 
> David,
> 
> Christopher
> still have to

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 7 May 2015 01:05:28 +0000

Tom, 

You are correct - credits are on a per-destination basis, but once you turn them on, it's bi-directional. It is possible for a router implementation to be minimal - for an example, the router would initialize the window to the maximum value, then 
 - as packets come in from the modem, they are counted. 
 - when the window is <= some pre-determined value (e.g., 50%? of max;  80%? Of max, pick a number), then issue a credit grant to the radio, altering window back up to maximum. 

In other words, the router simply tries to keep the window at maximum. Having implemented that before, I can say it's pretty straightforward. 

Regards,
Stan

> From: Goff, Thomas [mailto:[email-masked]]
> Sent: Wednesday, May 06, 2015 7:19 PM
> To: Ratliff, Stanley; Wiggins, David - 0665 - MITLL; [email-masked]
> Just to clarify, by unidirectional credit-windowing I was referring to credit
> granting by only one DLEP participant (e.g. the modem) for a destination; the
> other participant (e.g. the router) would not grant credits for that
> destination.  Is this supported by the current DLEP credit-windowing
> approach?
> 
> is that the receiver is effectively granting initial credits by "initializing its
> receive window".  At that point credit windowing is active for the destination
> in both directions and each side is responsible for granting credits on its
> receive window.  Is that a misinterpretation?
> 
>   Tom
> 
> > > >- Support the use of unidirectional credit-windowing where each
> > > >DLEP participant can decided if credits should be used for data it
> > receives
> > > advertise support of the credit-windowing extension to enable its
> > > peer
> > to
> > > received initialization signal from its peer." (3.1) However,
> > > whenever
> > the