Subject: [manet] DLEP Credit Windowing

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 15 Oct 2015 12:25:20 +0000

Hello Team,

I have a comment regarding the credit windowing scheme on the DLEP draft. These credits are exchanged through control plane packets, and these schemes will work well for routers where the control and data planes are converged. When the control and data planes are separate, translating these credit exchanges to packet rate flow control in hardware (e.g. ASICs) is a difficult practical issue.

I understand that the PPPoE scheme in RFC 5578 employed a credit scheme and a similar scheme has been carried forward for DLEP as well. However, there is a big difference between running credits over PPPoE sessions and Ethernet based forwarding where there is no notion of a "session". For instance, even if we program a certain number of bytes to be forwarded on an Ethernet port on an ASIC, after a while the packets lying in the queue will be dropped.

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.

I would suggest the authors to consider removing the credit windowing scheme from DLEP and defer to Ethernet flow-control.

Thanks
-Ashish

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Oct 2015 15:05:56 +0200

On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
<[email-masked]> 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

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 15 Oct 2015 14:49:45 +0000

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: [email-masked]
Subject: Re: [manet] DLEP Credit Windowing

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Oct 2015 16:52:34 +0200

Hi,

this sounds like a very interesting thing (we experimented with PAUSE
for some time but didn't know about the extension)... do you know if
its implemented in Linux?

Henning Rogge

On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela)
<[email-masked]> 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
>
>

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Oct 2015 17:48:03 +0200

PFC would be a HW or driver function.
I don't think PFC solves flow control to remote nodes. This requires per destination signaling.
I agree on having a requirement for diffserv based packet dispatcher with AQM and flow isolation. FIFO and priority queues should be something of the past. This is to be discussed after having a Credit-Windowing-00 draft. 

Teco 

> Op 15 okt. 2015, om 16:52 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> 
> Hi,
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 15 Oct 2015 15:54:12 +0000

As Teco indicates, the plan (I'm not an author, but I talked to one recently) is to separate the credit windowing out. So these discussions won't hold up the main part of DLEP, and it being WGLCed again.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 15 October 2015 16:48
To: Henning Rogge; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [manet] DLEP Credit Windowing

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Teco 

>> 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
>> 
>> 
>>> 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.

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 15 Oct 2015 15:59:21 +0000

>> I don't think PFC solves flow control to remote nodes. This requires per destination signaling.

What remote nodes are we talking about? I thought the radio is directly connected to a router. However, even if we assume there is a transparent bridge in between, and if the bridge supports PFC, then the radio will selectively pause the bridge which will buffer packets until it runs out of the buffer and then pauses the router. 

PFC works for any number of network devices as long as all those devices support PFC.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 9:18 PM
To: Henning Rogge <[email-masked]>; Ashish Dalela (adalela) <[email-masked]>
Cc: [email-masked]
Subject: Re: [manet] DLEP Credit Windowing

Teco

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 15 Oct 2015 16:01:45 +0000

That is good then. My point is that we should remove credit windowing from this draft before we take it to RFC. We can then separately discuss credits (or an equivalent scheme whose purpose would be to allow a consistent scheme that can be practically implemented in both converged and separated control/data planes).
	
Thanks

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 9:24 PM
To: Teco Boot <[email-masked]>; Henning Rogge <[email-masked]>; Ashish Dalela (adalela) <[email-masked]>
Cc: [email-masked]
Subject: RE: [manet] DLEP Credit Windowing

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 15 October 2015 16:48
To: Henning Rogge; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [manet] DLEP Credit Windowing

*** WARNING ***

Teco 

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Oct 2015 18:05:57 +0200

> PFC works for any number of network devices as long as all those devices support PFC.

Teco is right...

one router, connected to one radio... which connects it to any number
of other radios.

one of the outgoing queues to a neighbor might be full, another one
might be empty.

With the PAUSE frame (QoS aware or not) you can only block the whole
connection between radio and router, but not per neighbor (as defined
by the destination MAC address).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Oct 2015 18:07:00 +0200

It would also enable this working group to define other "credit/flow
control" schemes without taking away the possible compatibility with
the PPPoE extension.

Henning Rogge

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 15 Oct 2015 16:15:55 +0000

OK, I understand now. You are saying that since Credits are coming with the Neighbor updates, they are about the neighbor. That's a fair point. With PFC you could support up to 7 neighbors (with one priority left for control plane). It may or not may not be enough, and for design reasons we might not like it. I can think of some alternatives, but instead of muddying the waters now, let's defer this issue to a discussion in a later draft, so long as we can remove the credit windowing from DLEP draft.

Thanks

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 9:36 PM
To: Ashish Dalela (adalela) <[email-masked]>
Cc: Teco Boot <[email-masked]>; [email-masked]
Subject: Re: [manet] DLEP Credit Windowing

Teco is right...

one router, connected to one radio... which connects it to any number of other radios.

one of the outgoing queues to a neighbor might be full, another one might be empty.

With the PAUSE frame (QoS aware or not) you can only block the whole connection between radio and router, but not per neighbor (as defined by the destination MAC address).

Henning Rogge

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 15 Oct 2015 17:28:49 +0000

Hello all, 

Well, I am an author, so I think I can speak authoritatively... ;-) 

Yes, the credit-windowing is split out. Credit windowing will be introduced as a working group document (splitting a WG doc into two docs implies that both are already WG docs). Further, the docs (DLEP and Credit Windowing) will contain normative references to each other, so they will progress in lock-step. You can expect the submissions within the next day or two. 

The credit windowing draft is written as an extension to DLEP. It is not, by definition, an expression of the *only form* of possible flow control. By that, I mean that a discussion on PAUSE frames, or some equivalent scheme, does *not* necessarily invalidate credit windowing. If  there is interest in creating another draft with an additional scheme, I would encourage someone in the WG to step up to the plate and write it.

With the normative cross-referencing, a re-litigation of credit windowing *will* hold up DLEP. 

Regards,
Stan

> From: manet [mailto:[email-masked]] On Behalf Of Ashish Dalela
> (adalela)
> Sent: Thursday, October 15, 2015 12:02 PM
> To: Dearlove, Christopher (UK) <[email-masked]>; Teco
> Boot <[email-masked]>; Henning Rogge <[email-masked]>
> Cc: [email-masked]
> That is good then. My point is that we should remove credit windowing from
> this draft before we take it to RFC. We can then separately discuss credits (or
> an equivalent scheme whose purpose would be to allow a consistent scheme
> that can be practically implemented in both converged and separated
> control/data planes).
> 
> Thanks
> 
> To: Teco Boot <[email-masked]>; Henning Rogge <[email-masked]>;
> Ashish Dalela (adalela) <[email-masked]>
> Cc: [email-masked]
> As Teco indicates, the plan (I'm not an author, but I talked to one recently) is
> to separate the credit windowing out. So these discussions won't hold up the
> main part of DLEP, and it being WGLCed again.
> 
> --
> Christopher Dearlove
> BAE Systems Applied Intelligence Limited Registered in England & Wales No:
> 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2
> 7YP
> 
> 
> 
> ----------------------! WARNING ! ---------------------- This message originates
> from outside our organisation, either from an external partner or from the
> internet.
> I agree on having a requirement for diffserv based packet dispatcher with
> AQM and flow isolation. FIFO and priority queues should be something of the
> past. This is to be discussed after having a Credit-Windowing-00 draft.
> 
> Teco
> 
> 
> This email and any attachments are confidential to the intended recipient
> and may also be privileged. If you are not the intended recipient please
> delete it from your system and notify the sender.

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 15 Oct 2015 18:59:07 +0100

Why should the credit windowing draft be referenced from the main draft? It's an extension, and not having that reference means that the main draft, over which I see a lot less controversy, wouldn't get held up by any delay (such as resolving this discussion) to credit windowing.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 15 Oct 2015, at 18:28, Ratliff, Stanley <[email-masked]> wrote:
> 
> Hello all, 
>

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Thu, 15 Oct 2015 18:25:37 +0000

I agree with Chris.  I thought the main advantage of splitting the
documents was so that core DLEP could proceed independent of credit
windowing.

David

On 10/15/15, 1:59 PM, "manet on behalf of Christopher Dearlove"
<[email-masked] on behalf of [email-masked]> wrote:

>Why should the credit windowing draft be referenced from the main draft?
>It's an extension, and not having that reference means that the main
>draft, over which I see a lot less controversy, wouldn't get held up by
>any delay (such as resolving this discussion) to credit windowing.
>
>-- 
>Christopher Dearlove
>> Yes, the credit-windowing is split out. Credit windowing will be
>>introduced as a working group document (splitting a WG doc into two docs
>>implies that both are already WG docs). Further, the docs (DLEP and
>>Credit Windowing) will contain normative references to each other, so
>>they will progress in lock-step. You can expect the submissions within
>>the next day or two.
>> 
>> The credit windowing draft is written as an extension to DLEP. It is
>>not, by definition, an expression of the *only form* of possible flow
>>control. By that, I mean that a discussion on PAUSE frames, or some
>>equivalent scheme, does *not* necessarily invalidate credit windowing.
>>If  there is interest in creating another draft with an additional
>>scheme, I would encourage someone in the WG to step up to the plate and
>>write it.
>> 
>>> Follow the 'Report Suspicious Emails' link on IT matters for
>>>instructions on
>>> reporting suspicious email messages.
>>> I don't think PFC solves flow control to remote nodes. This requires
>>>per
>>> destination signaling.
>>>>>> essence, we don¹t send credits before packets are forwarded. Rather
>>>recipient

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 15 Oct 2015 18:34:37 +0000

Sigh...

There's nothing like re-litigating things that happened 3 to 4 years ago. Folks, if we keep churning on this, we'll never accomplish anything. 

The base DLEP draft normatively references Credit windowing as an example of *how* to do an extension. The Credit windowing draft is the extension. 
Nothing says that credit windowing will be the *only* extension (in fact, I've heard of other extension drafts in the works). Also, *nothing* says that the credit windowing extension will be the only (or the best) draft for flow control. 

Let's stop making "the good" the enemy of "the perfect", and actually accomplish something before the WG gets shutdown for not producing anything. 

Alvaro and Justin - please feel free to comment. 

Stan

> From: Wiggins, David - 0665 - MITLL [mailto:[email-masked]]
> Sent: Thursday, October 15, 2015 2:26 PM
> To: Christopher Dearlove <[email-masked]>; Ratliff, Stanley
> <[email-masked]>
> Cc: [email-masked]
> >>>>> Op 15 okt. 2015, om 16:52 heeft Henning Rogge <[email-masked]>
> het
> >>>> volgende geschreven:
> >>>>
> >>>> Hi,
> >>>>
> >>>>>> PAUSE frames, which has further been enhanced by the PFC
> (802.1Qbb)
> >>> mechanism.
> >>>>>> In

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Oct 2015 20:38:50 +0200

> Nothing says that credit windowing will be the *only* extension (in fact, I've heard of other extension drafts in the works). Also, *nothing* says that the credit windowing extension will be the on…

I think having one extension to refer to from Core DLEP is quite a good thing.

The fact that it IS an extension makes it an optional feature of DLEP.

I am quite sure there is no "one size fits all" way to do Flow
Control... we will need (most likely multiple of them). But the Credit
Window extension will allow it to convert radios supporting the PPPoE
flow-control/metric extension easily to DLEP.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 15 Oct 2015 20:12:49 +0100

I would have said it was the other way round. I'm suggesting the good - grab your most of a loaf with DLEP that's not encumbered by credit windowing, demanding both proceed is the best that may delay the good.

> On 15 Oct 2015, at 19:34, Ratliff, Stanley <[email-masked]> wrote:
> 
> Sigh...
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 15 Oct 2015 19:22:13 +0000

On 10/15/15, 2:34 PM, "Ratliff, Stanley" <[email-masked]> wrote:

>Sigh...
>
>There's nothing like re-litigating things that happened 3 to 4 years ago.
>Folks, if we keep churning on this, we'll never accomplish anything.
>
>The base DLEP draft normatively references Credit windowing as an example
>of *how* to do an extension. The Credit windowing draft is the extension.
>Nothing says that credit windowing will be the *only* extension (in fact,
>I've heard of other extension drafts in the works). Also, *nothing* says
>that the credit windowing extension will be the only (or the best) draft
>for flow control. 
>
>Let's stop making "the good" the enemy of "the perfect", and actually
>accomplish something before the WG gets shutdown for not producing
>anything. 
>

In the -16 version of DLEP all I see is an *informative* reference to
RFC5578.  From the discussion on the thread, I'm sure that can't be what
you guys are talking about.  Did I miss the reference somewhere?

BTW, you wrote above that the "base DLEP draft normatively references
Credit windowing as an example".  An example shouldn't be normative.  If
the base draft references the new credit windowing draft as Informational,
there won't be a delay -- only normative references would hold a document
up.

Alvaro.

>> >>> That is good then. My point is that we should remove credit
>>windowing
>> >>>from
>> >>> to separate the credit windowing out. So these discussions won't
>>hold
>> >>>up the
>> >>> BAE Systems Applied Intelligence Limited Registered in England &
>>Wales
>> >>>No:
>> >>> ----------------------! WARNING ! ---------------------- This
>>message
>> >>>originates
>> >>> from outside our organisation, either from an external partner or
>>from
>> >>>the
>> >>> internet.

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Oct 2015 22:04:27 +0200

> Op 15 okt. 2015, om 21:12 heeft Christopher Dearlove <[email-masked]> het volgende geschreven:
> 

+1

Further discussions on this x-ref topic delay both of them.

Teco

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 15 Oct 2015 17:03:35 -0400

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) <[email-masked]
> 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
>
>

---

From: Justin Dean <[email-masked]>
Date: Fri, 16 Oct 2015 15:39:15 -0400

With the draft being split into two it will be more clear that the credit
windowing extension is an extension and not the only one possible.  I too
would encourage those with other thoughts on how to do things better to
write a draft and convince everyone on how it's better and we can go from
there.  The credit windowing draft might not be the perfect way to do it
but it doesn't need to be either.  Looking forward to seeing the updated
drafts.

Justin

On Thu, Oct 15, 2015 at 1:28 PM, Ratliff, Stanley <[email-masked]>
wrote:

> implies that both are already WG docs). Further, the docs (DLEP and Credit
> Windowing) will contain normative references to each other, so they will
> progress in lock-step. You can expect the submissions within the next day
> or two.
>
> The credit windowing draft is written as an extension to DLEP. It is not,
> by definition, an expression of the *only form* of possible flow control.
> By that, I mean that a discussion on PAUSE frames, or some equivalent
> scheme, does *not* necessarily invalidate credit windowing. If  there is
> interest in creating another draft with an additional scheme, I would
> encourage someone in the WG to step up to the plate and write it.
>

---

From: Rick Taylor <[email-masked]>
Date: Sat, 17 Oct 2015 10:00:01 +0000

Hi Ashish,

In the forthcoming draft-17 of DLEP, the credit windowing extension has been removed and placed into its own draft document, as several other people have expressed opinions about the credit windowing mechanism. By doing so, the authors hope that it becomes more obvious that the credit windowing extension is simply that, an extension; allowing those people who liked the PPPoE style credit windowing to continue to use it with DLEP, but allowing others to use DLEP without worrying about credit windowing.

Thanks for your comment,
Rick Taylor

From: manet [mailto:[email-masked]] On Behalf Of Ashish Dalela (adalela)
Sent: 15 October 2015 13:25
To: [email-masked]
Subject: [manet] DLEP Credit Windowing

Hello Team,

Thanks
-Ashish

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 17 Oct 2015 08:58:32 -0700

Hi Rick,

I thought the purpose of splitting off the credit window draft is to
accelerate DLEP? But now there is a normative reference to it from
DLEP, so there is really no gain at all. Also, it contradicts what
Alvaro wrote in a previous email:

> "BTW, you wrote above that the "base DLEP draft normatively references
Credit windowing as an example".  An example shouldn't be normative."

Also, the new draft was immediately posted as WG draft without asking
the WG for consensus to adopt it first. I am not opposed to adopting
it, but I think the process is a bit strange here.

Regard
Ulrich

On Sat, Oct 17, 2015 at 3:00 AM, Rick Taylor
<[email-masked]> wrote:
> Hi Ashish,
>
>
>
> In the forthcoming draft-17 of DLEP, the credit windowing extension has been
> removed and placed into its own draft document, as several other people have
> expressed opinions about the credit windowing mechanism. By doing so, the
> authors hope that it becomes more obvious that the credit windowing
> extension is simply that, an extension; allowing those people who liked the
> PPPoE style credit windowing to continue to use it with DLEP, but allowing
> others to use DLEP without worrying about credit windowing.
>
>
>
> Thanks for your comment,
>
> Rick Taylor
>
>
>
>
>
> I have a comment regarding the credit windowing scheme on the DLEP draft.
> These credits are exchanged through control plane packets, and these schemes
> will work well for routers where the control and data planes are converged.
> When the control and data planes are separate, translating these credit
> exchanges to packet rate flow control in hardware (e.g. ASICs) is a
> difficult practical issue.
>
>
>
> I understand that the PPPoE scheme in RFC 5578 employed a credit scheme and
> a similar scheme has been carried forward for DLEP as well. However, there
> is a big difference between running credits over PPPoE sessions and Ethernet
> based forwarding where there is no notion of a “session”. For instance, even
> if we program a certain number of bytes to be forwarded on an Ethernet port
> on an ASIC, after a while the packets lying in the queue will be dropped.
>
>
>
> I would suggest the authors to consider removing the credit windowing scheme
> from DLEP and defer to Ethernet flow-control.
>
>
>
> Thanks
>
> -Ashish
>
>
>
>

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 17 Oct 2015 12:50:40 -0400

Ulrich,

The credit windowing draft was submitted as a WG document since this was a
split of one WG doc (DLEP-16) into two. According to the guidance I had at
the time, from Lou Berger, that's acceptable since credit windowing was
already "accepted" by the WG (it was accepted as part of the original
DLEP).

Stan

---

From: Henning Rogge <[email-masked]>
Date: Sun, 18 Oct 2015 12:13:16 +0200

On Sat, Oct 17, 2015 at 6:50 PM, Stan Ratliff <[email-masked]> wrote:
> already "accepted" by the WG (it was accepted as part of the original DLEP).

I think it was also mentioned at the last IETF meeting that the plan
was to progress both drafts in parallel.

Henning Rogge

---

From: Lou Berger <[email-masked]>
Date: Sun, 18 Oct 2015 09:06:49 -0400

> already "accepted" by the WG (it was accepted as part of the original

I believe my statement was along the lines of it being perfectly reasonable 
to start a new document as a WG document when  it is split from an existing 
wg draft, and have seen this done before.

Either way it's the chairs call...

Lou

> ----------

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 18 Oct 2015 09:57:29 -0700

Understood.

Thanks
Ulrich

---

From: Justin Dean <[email-masked]>
Date: Sun, 18 Oct 2015 20:38:34 +0000

As it was a split and something that was discussed agreed upon at prague I
have no issue with it starting as a WG draft.