Subject: [manet] DLEP last call

From: Rick Taylor <[email-masked]>
Date: Fri, 18 Mar 2016 13:05:06 +0000

Hi All,

As we are looking to exit last-call with DLEP, has everyone had a chance 
to read and submit any review comments, as I'd ideally like to get 
draft-21 out ASAP and move the document up the chain.

The same applies to the credit windowing draft.

Cheers,

Rick

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 15:14:37 -0400

Stan, (Rick),
    One additional question WRT credit windows.  The text says:

   The number of credits needed for a given transmission is the length
   of the data portion of the packet at the MAC layer.  When sending
   data to a credit enabled peer, the sender MUST decrement the
   appropriate window by the size of the data being sent, prior to
   encapsulation at the MAC layer.  When traffic is received, the
   receiver MUST decrement its own window after decapsulation at the MAC
   layer.

Doesn't it make sense to include the MAC header & perhaps padding as
they may account for a non-negligible portion of a small packet/frame? 
Or are ethernet headers and padding never sent over the RF channel?  If
this is a per radio 'thing' how is this indicated and how does it impact
processing?

Thanks,
Lou

On 3/18/2016 9:05 AM, Rick Taylor wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 15:20:01 -0400

Lou,

> this is a per radio 'thing' how is this indicated and how does it impact

The MAC header is fixed. Same with the Ethernet header. The intent was to
count the bytes that are queued to go into L2/L1 encap (or sent up after
L1/L2 de-encapsulation). As for "per radio", it's indicated in the Peer
Init/Peer Init response (you either support the extension or you don't),
then again at Destination Up/Destination Announce.

Regards,
Stan

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 15:29:02 -0400

Stan,

Let me try a different tact:

    Is the MAC header sometimes/never/always transmitted over the air?

    If sometimes, under what conditions?

Thanks,
Lou

On 3/18/2016 3:20 PM, Stan Ratliff wrote:
> Lou, 
>
>
> On Fri, Mar 18, 2016 at 3:14 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Stan, (Rick),
> The MAC header is fixed. Same with the Ethernet header. The intent was
> to count the bytes that are queued to go into L2/L1 encap (or sent up
> after L1/L2 de-encapsulation). As for "per radio", it's indicated in
> the Peer Init/Peer Init response (you either support the extension or
> you don't), then again at Destination Up/Destination Announce. 
>
> Regards,
> Stan
>
>  
>
>
>     Thanks,
>     Lou
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 15:33:06 -0400

>     Is the MAC header sometimes/never/always transmitted over the air?

OTA - depends on the radio architecture.

>     If sometimes, under what conditions?

802.11, for example, transmits the MAC OTA.

Regards,
Stan

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 16:00:03 -0400

On 3/18/2016 3:33 PM, Stan Ratliff wrote:
>
>
> On Fri, Mar 18, 2016 at 3:29 PM, Lou Berger <[email-masked]

doesn't whatever goes over the air, including header and padding, need
to be part of the credits?

eg I have 1000bytes of credits. 

In the case of a radio that  that includes 14byte header and 4 bytes
trailer on -air and no preamble of IPG.  This means the credit allows:
-  one IP packet of 982 bytes total length (1000-18 * 1, including IP
header), or
- 15 minimum size packets w/o padding for at total of 690 total length
(64-18 * 15, including IP header),

or in the case where the MAC header and trailer don't get transmitted,
the router can send a 1000 byte IP packet.

How is a router to know what to include?  I think the router needs to be
told what to do.  Perhaps have the radio just tell the router how many
bytes to include per packet (e.g., 0, 18,  38 bytes) and if frame
padding is included in the credits?

Lou

>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Stan, (Rick),
>     >     this is a per radio 'thing' how is this indicated and how
>     does it
>     >     impact
>     >     processing?
>     >
>     >
>     >     > As we are looking to exit last-call with DLEP, has
>     everyone had
>     >     a chance
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 16:03:11 -0400

> padding is included in the credits?

I can go with a scheme where the MAC header is included in the credit
counts. That gets everything through the MAC layer. Padding, if it occurs
at Layer 1, is outside the scope of the draft, IMO.

Regards,
Stan

> >     >        receiver MUST decrement its own window after decapsulation
> at
> >     >     the MAC
> >     >        layer.
> >     >
> >     >

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 16:20:28 -0400

Stan,

On 3/18/2016 4:03 PM, Stan Ratliff wrote:
>
>
> On Fri, Mar 18, 2016 at 4:00 PM, Lou Berger <[email-masked]
> counts. That gets everything through the MAC layer.
Isn't this per radio? if so, doesn't it need to be indicated in the
protocol?

> Padding, if it occurs at Layer 1, is outside the scope of the draft, IMO. 
>
l2 padding.  L1 encoding expansion is another matter that I wasn't
planning on bringing up...

Thanks,
Lou

>     >     > On Fri, Mar 18, 2016 at 3:14 PM, Lou Berger
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >
>     >     >     Stan, (Rick),
>     >     >        The number of credits needed for a given
>     transmission is
>     >     the length
>     >     >        of the data portion of the packet at the MAC
>     layer.  When
>     >     sending
>     >     >        receiver MUST decrement its own window after
>     decapsulation at
>     >     >     the MAC
>     >     >        layer.
>     >     >
>     >     >
>     >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 16:25:32 -0400

> planning on bringing up...

Seems like something that is a statistical 'fly on the elephant's rear'...
however, to reach a conclusion -  would adding some text along the lines of
"Credit counts MUST include the payload, the MAC header, and any padding
included at the MAC layer." allay your concern???

Regards,
Stan

> >     >     >     Or are ethernet headers and padding never sent over the
> RF
> >     >     >     channel?  If

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 16:52:25 -0400

On 3/18/2016 4:25 PM, Stan Ratliff wrote:
>
>
> On Fri, Mar 18, 2016 at 4:20 PM, Lou Berger <[email-masked]
>     >     > On Fri, Mar 18, 2016 at 3:29 PM, Lou Berger
>     >     How is a router to know what to include?  I think the router
>     needs
>     >     to be
> Seems like something that is a statistical 'fly on the elephant's rear'
whatever.

> ... however, to reach a conclusion -  would adding some text along the
> lines of "Credit counts MUST include the payload, the MAC header, and
> any padding included at the MAC layer." allay your concern??? 
>
If the macs over went over the air, i.e., the resource being metered ,
 > OTA - depends on the radio architecture.
So I don't understand how it can't be an indicated thing.

Either add a bit to the Credit Grant or add two extension types and move on.

Lou

>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>     >     >     >
>     >     >     >     Stan, (Rick),
>     >     >     >        appropriate window by the size of the data
>     being sent,
>     >     >     prior to
>     >     >     >     Doesn't it make sense to include the MAC header
>     & perhaps
>     >     >     padding as
>     >     >     >     they may account for a non-negligible portion of
>     a small
>     >     >     packet/frame?
>     >     >     >     Or are ethernet headers and padding never sent
>     over the RF
>     >     >     >     channel?  If
>     >     >     > The MAC header is fixed. Same with the Ethernet
>     header. The
>     >     >     intent was
>     >     >     > to count the bytes that are queued to go into L2/L1
>     encap (or
>     >     >     sent up
>     >     >     >     > to read and submit any review comments, as I'd
>     ideally
>     >     >     like to get
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 17:02:37 -0400

> So I don't understand how it can't be an indicated thing.

Credits aren't intended to compensate for OTA transmission - they're only
good between local modem and router. This is just intended to say, at the
link level between the DLEP partners, "send me <blah> octets, then pause
unless/until I tell you to send me more" Nothing about OTA expressed or
implied.

Stan

> >     >     >     >         One additional question WRT credit windows.
> The
> >     >     text says:
> >     >     >     >
> >     >     >     > the Peer Init/Peer Init response (you either support
> the
> >     >     >     extension or

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Mar 2016 18:52:10 -0400

Stan,

On 3/18/2016 5:02 PM, Stan Ratliff wrote:
>
>
> On Fri, Mar 18, 2016 at 4:52 PM, Lou Berger <[email-masked]
>     >     > On Fri, Mar 18, 2016 at 4:00 PM, Lou Berger
>     >     >     >         Is the MAC header sometimes/never/always
>     transmitted
>     >     >     over the air?
>     >     >     >
>     >     >     >
>     >     >     In the case of a radio that  that includes 14byte
>     header and
>     >     4 bytes
>     >     >     bytes to include per packet (e.g., 0, 18,  38 bytes)
>     and if
>     >     frame
> Credits aren't intended to compensate for OTA transmission - they're
> only good between local modem and router.

huh?  I think you lost me.

> This is just intended to say, at the link level between the DLEP
> partners, "send me <blah> octets, then pause unless/until I tell you
> to send me more" Nothing about OTA expressed or implied. 
>

Then what's the purpose of this extension?  I thought it was all about
OTA (RF) bandwidth usage?

BTW

  1.  Introduction

   In the world of radio-based networking, there are modems that need
   fine-grained flow control over traffic ingressing from a LAN
   connection, bound for transmission over the RF.  The need for such
   fine-grained control can exist for multiple reasons.  For example,
   radio devices are typically connected to the network by Ethernet.
   The capacity of an Ethernet link is normally far superior to that of
   the RF, leading to the possibility of overruns and dropped traffic.
   This is exacerbated by the fact that RF link capacity can vary from
   moment to moment, for an indeterminate amount of time.  Additionally,
   the capacity of the link can vary greatly depending on the
   destination, due to factors such as obstructions or multipath fading.

   These challenges motivate the requirement for a fine-grained flow
   control in radio-based communications - one that can support
   different window sizes for each destination accessed across the RF
   network.  To address this requirement, this document describes an
   extension to the Dynamic Link Event Protocol ([DLEP]), allowing for a
   Credit windowing scheme to be implemented on a destination-by-
   destination basis.

Lou

>     >     >     >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >     >     >     > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> wrote:
>     >     >     >     >
>     >     >     >     >     Stan, (Rick),
>     >     >     >     >         One additional question WRT credit
>     windows.  The
>     >     >     text says:
>     >     >     >     >
>     >     >     >     >        data to a credit enabled peer, the
>     sender MUST
>     >     >     decrement the
>     >     >     >     >        encapsulation at the MAC layer.  When
>     traffic is
>     >     >     >     received, the
>     >     >     >     > after L1/L2 de-encapsulation). As for "per
>     radio", it's
>     >     >     indicated in
>     >     >     >     > the Peer Init/Peer Init response (you either
>     support the
>     >     >     >     extension or
>     >     >     >     > you don't), then again at Destination
>     Up/Destination
>     >     Announce.
>     >     >     >     >
>     >     >     >     > Regards,
>     >     >     >     > Stan
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >     Thanks,
>     >     >     >     >     Lou
>     >     >     >     >
>     >     >     >     >     > draft-21 out ASAP and move the document
>     up the
>     >     chain.
>     >     >     >     >     >
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>

---

From: Lou Berger <[email-masked]>
Date: Sat, 19 Mar 2016 08:36:42 -0400

Stan,

On second thought:

On 3/18/2016 4:25 PM, Stan Ratliff wrote:
>
> ...-  would adding some text along the lines of "Credit counts MUST
> include the payload, the MAC header, and any padding included at the
> MAC layer." allay your concern???
> ...

This works for me. 

Lou