Re: [manet] DLEP Credit Windowing

["Arun Parashar (arparash)" <[e-mail]>]

Hi Rick,

>>I'm afraid I must have missed something - the original Credit Windowing draft has no requirement to hold a TCP window in the data plane. I guess there would be an issue if the DLEP code itself was in the control plane, which would necessitate control plane/data plane chatter to keep counts consistent, but you'll have that problem irrespective of the approach, wouldn't you?

Let’s take the case of data plane is handled in asic (which is normally the case), how does asic handle dlep credit windowing exchange credits? This problem requires control plane involvement and thereby the chatter between control/data plane to calculate and sync credits, which is why we are proposing to use what is now the standard for ethernet flow control (802.1Qbb aka PFC). PFC based schemes don’t have any control plane involvement, PFC pause/resume packets are handled at L2 layer itself (a wide support of it is already there).

>> One other point I've neglected to mention - the current Credit Windowing draft allows a partner to flow-control a single MAC address, while >> keeping traffic to other destinations (via the same radio). I don't believe PFC allows for that level of granularity.

I think you are mixing 802.3x flow control and PFC, what we are proposing is use of IEEE 802.1Qbb aka PFC. The PFC based schemes proposed in the draft does allow per radio granularity in fact it provides even better granularity “per traffic class per radio”. Please see the attached picture which describes the scenario with PFC, neighbor can be identified using MAC or VLAN or CoS based on the schemes listed in the draft.

In the attached figure, the impact matrix would look as follows -

1.      Traffic Class ‘X’ destined to R2 - Paused

2.      Other Traffic Classes destined to R2 – Not Impacted

3.      Traffic destined to R3 – Not Impacted

Hope it helps to clarify the query.

-Arun

From: Stan Ratliff [mailto:[e-mail]]
Sent: Wednesday, March 30, 2016 12:32 AM
To: Ashish Dalela (adalela) <[e-mail]>
Cc: Rick Taylor <[e-mail]>; Arun Parashar (arparash) <[e-mail]>; [e-mail]
Subject: Re: [manet] DLEP Credit Windowing

Ashish,


On Tue, Mar 29, 2016 at 11:12 AM, Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>> wrote:
Hello Rick,

Arun and I are co-authors. So, let me try to respond to you. The proposal for VLAN came about because we wanted to implement PFC as the flow-control mechanism instead of the credit-windowing scheme currently proposed. The reason is that if we separate control and data planes, then holding a TCP window in the data plane is very hard to achieve.

I'm afraid I must have missed something - the original Credit Windowing draft has no requirement to hold a TCP window in the data plane. I guess there would be an issue if the DLEP code itself was in the control plane, which would necessitate control plane/data plane chatter to keep counts consistent, but you'll have that problem irrespective of the approach, wouldn't you?

One other point I've neglected to mention - the current Credit Windowing draft allows a partner to flow-control a single MAC address, while keeping traffic to other destinations (via the same radio). I don't believe PFC allows for that level of granularity.

Regards,
Stan


HW based data planes, don't support TCP windows. Moreover, PFC is the standard way of dealing with flow-control over Ethernet.

Now, the issue is that PFC allows only 8 CoS queues, so that would limit us to only 8 neighbors and/or flows. That was perceived as a limitation. Hence the use of VLANs to identify neighbors.

We understand that in current DLEP a single L2 network is assumed between the radios and the radio/router. So, VLANs can be used only between the radio and router, in case there are no VLANs between the radios. These VLANs will help us identify multiple neighbors, and PFC + VLAN will help us pause a particular neighbor. If, however, someone feels the need to use multiple VLANs between the radios, that would be achieved by VLAN-in-VLAN, and so forth.

Bottom line, the VLAN proposal is driven by the need for flow-control, using a standard Ethernet based scheme, because in the control-data plane separation scenario, we don't have the alternative to use the current credit-window scheme.

Thanks

-----Original Message-----
From: manet [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Rick Taylor
Sent: Tuesday, March 29, 2016 5:57 PM
To: Arun Parashar (arparash) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [manet] DLEP Credit Windowing

Hi Arun,

I have two concerns regarding your drafts:

1) DLEP isn't finished yet, and so I don't think any extensions will proceed until then.

2) I still have worries about the use of VLANs per neighbour.  Given the single layer-2 requirement of DLEP, I don't see how this will work.

Will you be in Argentina?  If so, I would be happy to talk over my concerns face to face.

Cheers,

Rick

On 28/03/16 06:50, Arun Parashar (arparash) wrote:
> Hi All,
>
> Has everyone had chance to read and submit the review comments, we would like to hear comments/concerns before we take these two documents further in the chain.
>
> 1. VLANs and DLEP draft -
> https://tools.ietf.org/html/draft-dalela-vlans-and-dlep-01
> 2. Flow Control draft -
> https://tools.ietf.org/html/draft-dalela-dlep-flow-control-02
>
> -Arun
>
> -----Original Message-----
> From: Arun Parashar (arparash)
> Sent: Tuesday, March 15, 2016 9:10 PM
> To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Stan Ratliff
> <[e-mail]<mailto:[e-mail]>>; Henning Rogge <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>>
> Subject: RE: [manet] DLEP Credit Windowing
>
> Hi Rick, Stan,
>
> Per comments, VLAN topic is dealt in separate draft and flow control draft is updated accordingly.
>
> 1. VLANs and DLEP draft -
> https://tools.ietf.org/html/draft-dalela-vlans-and-dlep-01
> 2. Flow Control draft -
> https://tools.ietf.org/html/draft-dalela-dlep-flow-control-02
>
> Request comments.
>
> -Arun
>
> -----Original Message-----
> From: manet [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ashish Dalela
> (adalela)
> Sent: Friday, March 04, 2016 9:21 PM
> To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Stan Ratliff
> <[e-mail]<mailto:[e-mail]>>; Henning Rogge <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [manet] DLEP Credit Windowing
>
> Hi Rick,
>
> Sure, that can be done. This draft is to seek the inputs and feedback
> on what is the best path for us. Any and all suggestions are welcome,
> including "this is a very bad idea" :-)
>
> Thanks
>
> -----Original Message-----
> From: Rick Taylor [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Friday, March 04, 2016 8:32 PM
> To: Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>>; Stan Ratliff
> <[e-mail]<mailto:[e-mail]>>; Henning Rogge <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [manet] DLEP Credit Windowing
>
> Hi Ashish,
>
> Okay, I understand that the VLAN's don't extend over the 'air'.  My issue with them is between router and modem - as core DLEP stands, your method is not allowed.
>
> However, it can be allowed in the way you describe via an extension, as you have already done.  My concern is not "VLANs can be used without PFC, and PFC can be used without VLAN", it is that core DLEP and VLANs doesn't work.
>
> I would much rather have an extension entitled "VLANs and DLEP" that covers the VLAN topic in isolation.  And an updated version of your draft covering PFC-based flow control, referring to the VLAN extension if VLANs are in use.
>
> Sorry, I don't mean to be negative, the PFC part of your draft seems excellent.
>
> Cheers,
>
> Rick
>
> On 04/03/16 14:20, Ashish Dalela (adalela) wrote:
>> Hi Rick,
>>
>> The usage of the VLAN is limited to that between the router and the modem. It doesn't stretch to neighbors. In other words, the VLAN is not seen on the radio network. It is added by the modem and the router when forwarding packets to each other, and stripped when then packet exits the router (towards another router) or the modem (towards another modem). This clarification can be added to the next version if that would help.
>>
>> PFC based flow-control only gives us 8 neighbors with one traffic class each. And usage of VLAN alone doesn't imply the use of PFC per VLAN. That's why it is important to combine them.
>>
>> Currently VLANs can be used without PFC, and PFC can be used without VLAN. So, separating them will not achieve the key purpose of flow control.
>>
>> Thanks
>> Ashish
>>
>> -----Original Message-----
>> From: Rick Taylor [mailto:[e-mail]<mailto:[e-mail]>]
>> Sent: Friday, March 04, 2016 7:28 PM
>> To: Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>>; Stan Ratliff
>> <[e-mail]<mailto:[e-mail]>>; Henning Rogge <[e-mail]<mailto:[e-mail]>>
>> Cc: [e-mail]<mailto:[e-mail]>
>> Subject: Re: [manet] DLEP Credit Windowing
>>
>> Hi Ashish,
>>
>> Introducing a VLAN per neighbour is actually quite a big change from core DLEP.  Destinations (neighbours) in DLEP are distinguished by MACs that are MUST be addressable/reachable on the same (V)LAN segment as the DLEP peers.
>>
>> What you are proposing with VLAN-per-destination looks a lot more
>> like the draft extension I put forward for layer-3 DLEP
>> (https://tools.ietf.org/html/draft-taylor-manet-l3-dlep-00) where I proposed the workaround of stating that the MAC address is no longer a MAC, just an identifying unique sequence of octets.
>>
>> In your case the additional VLAN-Id data item paired with the MAC becomes the unique destination identifier.
>>
>> Might I suggest that you actually have 2 extensions in this one draft:
>> Per-VLAN destinations, and PFC based flow control?  Maybe splitting the document into two might be clearer for the readers?
>>
>> Cheers,
>>
>> Rick
>>
>> On 04/03/16 12:26, Ashish Dalela (adalela) wrote:
>>> Hi Rick,
>>>
>>> Yes, one of the proposals is to use a VLAN per neighbor. The default VLAN 1 will be used for the control plane. That allows us to have 4K neighbors, each distinguished by a unique VLAN ID.
>>>
>>> Thanks
>>>
>>> Ashish
>>>
>>> -----Original Message-----
>>> From: Rick Taylor [mailto:[e-mail]<mailto:[e-mail]>]
>>> Sent: Friday, March 04, 2016 5:17 PM
>>> To: Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>>; Stan Ratliff
>>> <[e-mail]<mailto:[e-mail]>>; Henning Rogge <[e-mail]<mailto:[e-mail]>>
>>> Cc: [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [manet] DLEP Credit Windowing
>>>
>>> Hi Ashish,
>>>
>>> Thank you for this, it looks extremely interesting.
>>>
>>> Obviously I haven't had a chance to completely digest the draft, but one thing that leaps out to me is the use of VLAN tagging, specifically section 7.  Are you suggesting that the DLEP session runs over a VLAN trunk between router and modem (somehow) and the VLANs then fan out at the modem in some way?
>>>
>>> Given the 'transparent layer-2' requirement of DLEP, how do you see this working with your model of a VLAN per destination (for flow control), or have I misunderstood what you are proposing?
>>>
>>> Regards
>>>
>>> Rick
>>>
>>> On 04/03/16 10:43, Ashish Dalela (adalela) wrote:
>>>> Hello Stan,
>>>>
>>>> We have submitted a new draft today to describe the PFC flow
>>>> control mechanism. Sorry, this was long due on me; but better late than never!
>>>>
>>>> https://datatracker.ietf.org/doc/draft-dalela-dlep-flow-control/
>>>>
>>>> Here is the quick rationale underlying this draft. The current DLEP
>>>> credit window scheme requires credits exchanged over a TCP session.
>>>> This is harder to achieve in many scenarios because many data path
>>>> implementations are incapable of handling TCP windowing. So we are
>>>> suggesting an alternative approach that utilizes IEEE 802.1Qbb (a.k.a.
>>>> PFC).
>>>>
>>>> Request comments.
>>>>
>>>> Thanks
>>>>
>>>> -Ashish
>>>>
>>>> *From:*Stan Ratliff [mailto:[e-mail]<mailto:[e-mail]>]
>>>> *Sent:* Friday, October 16, 2015 2:34 AM
>>>> *To:* Ashish Dalela (adalela) <[e-mail]<mailto:[e-mail]>>
>>>> *Cc:* Henning Rogge <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
>>>> *Subject:* Re: [manet] DLEP Credit Windowing
>>>>
>>>> Ashish,
>>>>
>>>> If you'd like to write a proposed DLEP extension using PFC, I
>>>> encourage you to do so. As Henning mentioned, more than 1 flow
>>>> control mechanism is likely for DLEP.
>>>>
>>>> Stan
>>>>
>>>> On Thu, Oct 15, 2015 at 10:49 AM, Ashish Dalela (adalela)
>>>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>
>>>>        Yes it will and that's why I suggested the use of PFC. The control
>>>>        and data planes will have different priorities. The radio never
>>>>        pauses the control channel because it is never sent over the air. If
>>>>        desired,  the data packets themselves could be given different
>>>>        priorities allowing some flows to be selectively paused.
>>>>
>>>>        Sent from Samsung Mobile
>>>>
>>>>
>>>>
>>>>        -------- Original message --------
>>>>        From: Henning Rogge
>>>>        Date:15/10/2015 18:36 (GMT+05:30)
>>>>        To: "Ashish Dalela (adalela)"
>>>>        Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>        Subject: Re: [manet] DLEP Credit Windowing
>>>>
>>>>        On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
>>>>        <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>        > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE
>>>>        > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. In
>>>>        > essence, we don't send credits before packets are forwarded. Rather we pause
>>>>        > the traffic when the traffic cannot be forwarded and the buffers are full.
>>>>        > PFC is widely used in a number of Ethernet flow-control scenarios today.
>>>>
>>>>        Would a 802.3 PAUSE Frame not also block the DLEP control channel?
>>>>
>>>>        Henning Rogge
>>>>
>>>>
>>>>        _______________________________________________
>>>>        manet mailing list
>>>>        [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>        https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> manet mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet
>


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

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