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

[Rick Taylor <[e-mail]>]

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:[e-mail]] 
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.
>
>  
>
> 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:[e-mail]] *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,
>
>  
>
> 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 
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> >Date: Fri, 18 Mar 2016 16:25:32 -0400
> >From: Stan Ratliff <[e-mail] 
> ><mailto:[e-mail]>>
> >Message-ID:
>        
> <[e-mail]
> <mailto:CALtoyok6eh0dXQzxWCx%2B%2Bi_K4k0dtenthXheuLEQFYcVdrmdhg@mail.g
> mail.com>>
> >
> >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
>
>  
>
>
> _______________________________________________
> manet mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/manet
>
>  
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet