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:manet-bounces@ietf.org] On Behalf Of Ashish Dalela (adalela)
Sent: Friday, March 04, 2016 9:21 PM
To: Rick Taylor <rick@tropicalstormsoftware.com>; Stan Ratliff <ratliffstan@gmail.com>; Henning Rogge <hrogge@gmail.com>
Cc: manet@ietf.org
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:rick@tropicalstormsoftware.com]
Sent: Friday, March 04, 2016 8:32 PM
To: Ashish Dalela (adalela) <adalela@cisco.com>; Stan Ratliff <ratliffstan@gmail.com>; Henning Rogge <hrogge@gmail.com>
Cc: manet@ietf.org
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:rick@tropicalstormsoftware.com]
> Sent: Friday, March 04, 2016 7:28 PM
> To: Ashish Dalela (adalela) <adalela@cisco.com>; Stan Ratliff 
> <ratliffstan@gmail.com>; Henning Rogge <hrogge@gmail.com>
> Cc: manet@ietf.org
> 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:rick@tropicalstormsoftware.com]
>> Sent: Friday, March 04, 2016 5:17 PM
>> To: Ashish Dalela (adalela) <adalela@cisco.com>; Stan Ratliff 
>> <ratliffstan@gmail.com>; Henning Rogge <hrogge@gmail.com>
>> Cc: manet@ietf.org
>> 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:ratliffstan@gmail.com]
>>> *Sent:* Friday, October 16, 2015 2:34 AM
>>> *To:* Ashish Dalela (adalela) <adalela@cisco.com>
>>> *Cc:* Henning Rogge <hrogge@gmail.com>; manet@ietf.org
>>> *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) 
>>> <adalela@cisco.com <mailto:adalela@cisco.com>> 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: manet@ietf.org <mailto:manet@ietf.org>
>>>       Subject: Re: [manet] DLEP Credit Windowing
>>>
>>>       On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
>>>       <adalela@cisco.com <mailto:adalela@cisco.com>> 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
>>>       manet@ietf.org <mailto:manet@ietf.org>
>>>       https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>>
>
>

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet