Re: [manet] DLEP Credit Windowing

[Stan Ratliff <[e-mail]>]

Ashish,


On Tue, Mar 29, 2016 at 11:12 AM, Ashish Dalela (adalela) <[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]] On Behalf Of Rick Taylor
> Sent: Tuesday, March 29, 2016 5:57 PM
> To: Arun Parashar (arparash) <[e-mail]>; [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]>; Stan Ratliff
> > <[e-mail]>; Henning Rogge <[e-mail]>
> > Cc: [e-mail]; Ashish Dalela (adalela) <[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]] On Behalf Of Ashish Dalela
> > (adalela)
> > Sent: Friday, March 04, 2016 9:21 PM
> > To: Rick Taylor <[e-mail]>; Stan Ratliff
> > <[e-mail]>; Henning Rogge <[e-mail]>
> > Cc: [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]]
> > Sent: Friday, March 04, 2016 8:32 PM
> > To: Ashish Dalela (adalela) <[e-mail]>; Stan Ratliff
> > <[e-mail]>; Henning Rogge <[e-mail]>
> > Cc: [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]]
> >> Sent: Friday, March 04, 2016 7:28 PM
> >> To: Ashish Dalela (adalela) <[e-mail]>; Stan Ratliff
> >> <[e-mail]>; Henning Rogge <[e-mail]>
> >> Cc: [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]]
> >>> Sent: Friday, March 04, 2016 5:17 PM
> >>> To: Ashish Dalela (adalela) <[e-mail]>; Stan Ratliff
> >>> <[e-mail]>; Henning Rogge <[e-mail]>
> >>> Cc: [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]]
> >>>> *Sent:* Friday, October 16, 2015 2:34 AM
> >>>> *To:* Ashish Dalela (adalela) <[e-mail]>
> >>>> *Cc:* Henning Rogge <[e-mail]>; [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]>> 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]>
> >>>>        Subject: Re: [manet] DLEP Credit Windowing
> >>>>
> >>>>        On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
> >>>>        <[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]>
> >>>>        https://www.ietf.org/mailman/listinfo/manet
> >>>>
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> >
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>