Subject: Re: [manet] Question on draft-ietf-manet-credit-window-02

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Fri, 18 Mar 2016 16:50:12 -0500

>Date: Fri, 18 Mar 2016 16:25:32 -0400
>From: Stan Ratliff <[email-masked]>
>Message-ID:
        <[email-masked]>
>
>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

Because some radio networks have their own over-the-air (OTA) MAC and MAC
addressing between Modem devices (radios) different than they use for the
baseband (BB) MAC between the Modem device and Router (this is like the
logical tunneling between Modem devices mentioned in section 2 of DLEP-20),
I want to reiterate that we are talking about the BB MAC and not the OTA
MAC.

Router <==========> Modem <===========> Modem <===========> Router

           BB                  OTA                 BB

I work with a variety of different non-commercial MANET waveforms that have
different ways of sending the BB data OTA.  Most use IEEE 802.3 Ethernet or
PPP as the BB MAC between the Router and Modem.

Many send the entire BB MAC header + IP header + IP payload encapsulated in
the OTA MAC payload.

 Router <==========> Modem <===========> Modem <===========> Router

         +--------+          +--------+          +--------+

         |IP payld|          |IP payld|          |IP payld|

         +--------+          +--------+          +--------+

         | IP Hdr |          | IP Hdr |          | IP Hdr |

         +--------+          +--------+          +--------+

         | BB MAC |          | BB MAC |          | BB MAC |

         +--------+          +--------+          +--------+

                             | OTA MAC|

                             +--------+

Others compress the BB MAC header and only send the IP header + IP payload
encapsulated in the OTA MAC payload

 Router <==========> Modem <===========> Modem <===========> Router

         +--------+          +--------+          +--------+

         |IP payld|          |IP payld|          |IP payld|

         +--------+          +--------+          +--------+

         | IP Hdr |          | IP Hdr |          | IP Hdr |

         +--------+          +--------+          +--------+

         | BB MAC |          |compress|          | BB MAC |

         +--------+          +--------+          +--------+

                             | OTA MAC|

                             +--------+

Others compress both the BB MAC and IP headers before sending the
compressed header + IP payload encapsulated in the OTA MAC payload.

 Router <==========> Modem <===========> Modem <===========> Router

         +--------+          +--------+          +--------+

         |IP payld|          |IP payld|          |IP payld|

         +--------+          +--------+          +--------+

         | IP Hdr |          |compress|          | IP Hdr |

         +--------+          +--------+          +--------+

         | BB MAC |          | OTA MAC|          | BB MAC |

         +--------+          +--------+          +--------+

And the size of the compression can vary depending upon the prior and
current state of the headers and compression.

So of the choices

(1) include IP payload, IP header, and BB MAC in credit window

(2) include only the IP payload and IP header in the credit window

(3) include only the IP payload in the credit window

I RECOMMEND choice (1)because if the Modem does compression, then sometimes
the Router is paced even when it might have had space to send a little bit
more traffic.

But that is better than choices (2) or (3) because either

(a) cases arise where the headers have to be sent uncompressed and hence
the Router might think it has space to send more data when it really
didn’t, or

(b) the Modem always reserved extra space for uncompressed headers – but
because it doesn’t know if they are long or short IP packets, it has to
include a lot of excessive padding and hence could flow control the Router
when it doesn’t need to

-- 
James A. (Jim) Stevens, PhD
Network Architect / Technical Fellow
Rockwell Collins Government Systems

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 18 Mar 2016 22:34:47 -0400

Jim,

Thanks for that info. I'll be crafting text this weekend.

Regards,
Stan

On Fri, Mar 18, 2016 at 5:50 PM, James A. (Jim) Stevens <
[email-masked]> wrote:

>         <
> [email-masked]>
> >
> I work with a variety of different non-commercial MANET waveforms that
> have different ways of sending the BB data OTA.  Most use IEEE 802.3
> Ethernet or PPP as the BB MAC between the Router and Modem.
>
>
>
> Many send the entire BB MAC header + IP header + IP payload encapsulated
> in the OTA MAC payload.
>
>
>
> I RECOMMEND choice (1)because if the Modem does compression, then
> sometimes the Router is paced even when it might have had space to send a
> little bit more traffic.
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Rick Taylor <[email-masked]>
Date: Sat, 19 Mar 2016 12:51:40 +0000

I’m mostly on the side-lines for credit-windowing, but Jim’s choice 2 is what I have always assumed.

Given that the Layer-2 header size is known already by the router and modem, due to the single layer-2 requirement of DLEP, I don’t think it should be included in *any* metrics concerning ‘amounts of data’, e.g. Credit-windowing, CDR or MTU.  Even if the modem does clever compression/aggregation of headers (from any layer), that bit only runs between modems, and the DLEP data items are associated with Destinations, and the destination is not the remote modem, hence the ‘flow’ is:

BB MAC + IP Header + IP Payload<-local-> OTA Mac/Magic + Payload <-air-> OTA Mac/Magic + Payload <-local-> BB MAC + IP Header + IP Payload.

sizeof(BB Mac) is well-known by all DLEP participants, and sizeof(OTA MAC/Magic) is private to the modem implementation, hence credits should refer to sizeof(IP Header + IP Payload).

When comparing this to dlep-draft-20, the core spec makes no mention of layer-2 headers in the CDR/MDR data items (which also talk about ‘amounts of data’ – perhaps this needs clarifying), and explicitly excludes layer-2 headers in the MTU data item (as that is what is generally understood by MTU).

Cheers,

Rick

From: manet [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 19 March 2016 02:35
To: James A. (Jim) Stevens
Cc: MANET IETF
Subject: Re: [manet] Question on draft-ietf-manet-credit-window-02

Jim,

Regards,
Stan

On Fri, Mar 18, 2016 at 5:50 PM, James A. (Jim) Stevens <[email-masked]<mailto:[email-masked]>> wrote:
>From: Stan Ratliff <[email-masked]<mailto:[email-masked]>>
>Message-ID:
        <[email-masked]<mailto:[email-masked]>>
>included at the MAC layer." allay your concern???
Because some radio networks have their own over-the-air (OTA) MAC and MAC addressing between Modem devices (radios) different than they use for the baseband (BB) MAC between the Modem device and Router (this is like the logical tunneling between Modem devices mentioned in section 2 of DLEP-20), I want to reiterate that we are talking about the BB MAC and not the OTA MAC.

I work with a variety of different non-commercial MANET waveforms that have different ways of sending the BB data OTA.  Most use IEEE 802.3 Ethernet or PPP as the BB MAC between the Router and Modem.

Many send the entire BB MAC header + IP header + IP payload encapsulated in the OTA MAC payload.

Others compress the BB MAC header and only send the IP header + IP payload encapsulated in the OTA MAC payload

Others compress both the BB MAC and IP headers before sending the compressed header + IP payload encapsulated in the OTA MAC payload.

And the size of the compression can vary depending upon the prior and current state of the headers and compression.

So of the choices

I RECOMMEND choice (1)because if the Modem does compression, then sometimes the Router is paced even when it might have had space to send a little bit more traffic.

But that is better than choices (2) or (3) because either
(a) cases arise where the headers have to be sent uncompressed and hence the Router might think it has space to send more data when it really didn’t, or
(b) the Modem always reserved extra space for uncompressed headers – but because it doesn’t know if they are long or short IP packets, it has to include a lot of excessive padding and hence could flow control the Router when it doesn’t need to

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Lou Berger <[email-masked]>
Date: Sat, 19 Mar 2016 09:21:01 -0400

Rick,
    Take a look at the bandwidth impact of headers on small frames and
you'll see it's pretty significant.  If credits relate to OTA bandwidth,
IMO headers have to be included.  I don't have any strong
opinions/preferences on how this should be done for DLEP.  If credit
window does *not* relate to OTA bandwidth, then I personally think the
extension is overkill and I'd go for a PAUSE/PFC based approach.

Lou

PS we had the basically same drawn out "discussion" when defining
intserv and eventually agreed that headers have to taken into account as
part of bandwidth calculations.

On 3/19/2016 8:51 AM, Rick Taylor wrote:
> Given that the Layer-2 header size is known already by the router and
> modem, due to the single layer-2 requirement of DLEP, I don’t think it
> should be included in **any** metrics concerning ‘amounts of data’,
> e.g. Credit-windowing, CDR or MTU.  Even if the modem does clever
> compression/aggregation of headers (from any layer), that bit only
> runs between modems, and the DLEP data items are associated with
> Destinations, and the destination is not the remote modem, hence the
> ‘flow’ is:
>
>  
>
> BB MAC + IP Header + IP Payload<-local-> OTA Mac/Magic + Payload
> <-air-> OTA Mac/Magic + Payload <-local-> BB MAC + IP Header + IP Payload.
>
>  
>
> sizeof(BB Mac) is well-known by all DLEP participants, and sizeof(OTA
> MAC/Magic) is private to the modem implementation, hence credits
> should refer to sizeof(IP Header + IP Payload).
>
>  
>
> When comparing this to dlep-draft-20, the core spec makes no mention
> of layer-2 headers in the CDR/MDR data items (which also talk about
> ‘amounts of data’ – perhaps this needs clarifying), and explicitly
> excludes layer-2 headers in the MTU data item (as that is what is
> generally understood by MTU).
>
>  
>
> Cheers,
>
>  
>
> Rick
>
>  
>
>  
>
>  
>
> *From:*manet [mailto:[email-masked]] *On Behalf Of *Stan Ratliff
> *Sent:* 19 March 2016 02:35
> *To:* James A. (Jim) Stevens
> *Cc:* MANET IETF
> *Subject:* Re: [manet] Question on draft-ietf-manet-credit-window-02
>
>  
>
> Jim, 
>
>  
>
> On Fri, Mar 18, 2016 at 5:50 PM, James A. (Jim) Stevens
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> >From: Stan Ratliff <[email-masked] <mailto:[email-masked]>>
> >Message-ID:
>        
> <[email-masked]
> <mailto:[email-masked]>>
> >
> Because some radio networks have their own over-the-air (OTA) MAC and
> MAC addressing between Modem devices (radios) different than they use
> for the baseband (BB) MAC between the Modem device and Router (this is
> like the logical tunneling between Modem devices mentioned in section
> 2 of DLEP-20), I want to reiterate that we are talking about the BB
> MAC and not the OTA MAC.
>
>  
>
> Others compress the BB MAC header and only send the IP header + IP
> payload encapsulated in the OTA MAC payload
>
>  
>
> sometimes the Router is paced even when it might have had space to
> send a little bit more traffic.
>
>  
>
> (a) cases arise where the headers have to be sent uncompressed and
> hence the Router might think it has space to send more data when it
> really didn’t, or
>
> (b) the Modem always reserved extra space for uncompressed headers –
> but because it doesn’t know if they are long or short IP packets, it
> has to include a lot of excessive padding and hence could flow control
> the Router when it doesn’t need to
>
>  
>
> -- 
>
> [email-masked] <mailto:[email-masked]>

---

From: Rick Taylor <[email-masked]>
Date: Sat, 19 Mar 2016 13:51:06 +0000

Lou,

As mentioned before, credit windowing is not my document, and I may have misunderstood some of the fine details, but:

I believe credits do not directly map to OTA bandwidth (where I agree headers have a massive impact with small frames), and hence sub-IP headers should not be counted.

Yes, avoiding overloading of the OTA bandwidth is the purpose, but credit-windowing attempts to solve that problem by throttling at the LAN interface to the modem rather than the RF interface, and therefore flow control should be done with metrics that make sense on the LAN side.  Yes, any smart modem is going to have to do some on-the-fly calculation of credit windows given a clever OTA compression scheme, but that's the modem's business.  In my opinion, DLEP cannot make assumptions about what happens between modems - that way madness lies...

I agree, PAUSE/PFC is a viable alternative to what is being proposed in this draft, and hence I'm watching the new proposed DLEP extensions covering it with interest, but that doesn't invalidate this approach.

Rick

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 19 March 2016 13:21
To: Rick Taylor; Stan Ratliff; James A. (Jim) Stevens
Cc: MANET IETF
Subject: Re: [manet] Question on draft-ietf-manet-credit-window-02

Rick,
    Take a look at the bandwidth impact of headers on small frames and you'll see it's pretty significant.  If credits relate to OTA bandwidth, IMO headers have to be included.  I don't have any strong opinions/preferences on how this should be done for DLEP.  If credit window does *not* relate to OTA bandwidth, then I personally think the extension is overkill and I'd go for a PAUSE/PFC based approach.

Lou

PS we had the basically same drawn out "discussion" when defining intserv and eventually agreed that headers have to taken into account as part of bandwidth calculations.

On 3/19/2016 8:51 AM, Rick Taylor wrote:
>
> I'm mostly on the side-lines for credit-windowing, but Jim's choice 2 
> is what I have always assumed.
>
>  
>
> modem, due to the single layer-2 requirement of DLEP, I don't think it 
> should be included in **any** metrics concerning 'amounts of data', 
> 'flow' is:
> 'amounts of data' - perhaps this needs clarifying), and explicitly 
> >"Credit counts MUST include the payload, the MAC header, and any 
> >padding included at the MAC layer." allay your concern???
> >
> >Regards,
> >Stan
>
> really didn't, or
> (b) the Modem always reserved extra space for uncompressed headers - 
> but because it doesn't know if they are long or short IP packets, it 
> the Router when it doesn't need to
>
>  
>
> --
>