Subject: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-04.txt

From: [email-masked]
Date: Thu, 01 Mar 2018 13:45:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

        Title           : DLEP DiffServ Aware Credit Window Extension
        Authors         : Bow-Nan Cheng
                          David Wiggins
                          Lou Berger
	Filename        : draft-ietf-manet-dlep-da-credit-extension-04.txt
	Pages           : 26
	Date            : 2018-03-01

Abstract:
   This document defines an extension to the DLEP protocol that enables
   a DiffServ aware credit-window scheme for destination-specific and
   shared flow control.  The extension is logically composed of two
   mechanisms.  The first provides credit window control, the second
   identifies how flows are identified and mapped to a credit window.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-04
https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-credit-extension-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-da-credit-extension-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lou Berger <[email-masked]>
Date: Thu, 1 Mar 2018 18:03:46 -0500

Hi,

This version completes the updates discussed at the last IETF. The 
notable changes are:

- Separate credit control from traffic classification

- Ensure traffic classification is extendable to other flow 
identification methods

     - This included definition of a Notional Ethernet Credit Window 
Traffic Classification (in an appendix) as a sanity check on separation 
of mechanisms.  This can be removed at some point or moved to it's own 
document/extension.

- Add a management considerations section

- other minor corrections/fixes.

- One note, Traffic Class. Identifier (TID) was not changed as discussed 
at IETF 100

Lou

On 3/1/2018 4:45 PM, [email-masked] wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 2 Mar 2018 17:46:48 -0500

Hi,

There are a few items outstanding on the credit draft:

I received an offline comment that I think should be noted in the 
draft.  The comment was that it might not be obvious that since 
queues/credit windows can be shared among (disjoint) sets of endpoints, 
that sending to one destination in a set reduces the available capacity 
to other destinations.  I'll propose some text on this shortly.

There are also two questions that are still open:

(A) does the WG want to keep the document as is or break apart the 
current document into two documents?

- the first being the credit window and generic traffic classification  
definition and the second being the DA/DSCP extension and traffic 
classification sub-DI

I can't speak for my co-authors, but I'm okay proceeding either way, but 
now is the time to decide.

(B) finally, does the WG want to take the notional Ethernet/PCP based 
traffic classification which was added as an appendix, see [1], to 
sanity check the current functional decomposition and make it a full 
blown Ethernet/PCP extension

my personal preference is to do this, it's not much effort and seems 
worthwhile.

any thoughts and/or comments would be appreciated.

I also look forward to discussing this in London (in the joint meeting 
with ccamp).

Lou

[1] 
https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-04#appendix-B

---

From: Rick Taylor <[email-masked]>
Date: Sat, 3 Mar 2018 10:45:15 +0000

Hi Lou,

I'm starting to receive quite a few enquiries from industry for DLEP support for modem systems where different traffic classes flow via different paths to destinations, so called 'hub-assist' modems.  For these types of modem (an others) the ability to describe the metrics per-flow to a destination is required.

As I've mentioned before, I think there is benefit in splitting out the concept of Traffic Class Ids (as specified in this draft) into its own draft, including both the DSCP and Ethernet TOS examples, and then referring to that draft from this one, and also from others including 'metrics per TCID'. 

I'm in London, and do think this is a useful topic of conversation for the meeting/future work.  

@chairs: Would you like Lou or I to grab 10 mins at the mic to talk about this, or try to work it out offline?

Cheers,

Rick

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 02 March 2018 22:47
> To: [email-masked]
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-
> 04.txt
> 
> Hi,
> 
> I received an offline comment that I think should be noted in the draft.  The
> comment was that it might not be obvious that since queues/credit windows
> can be shared among (disjoint) sets of endpoints, that sending to one
> destination in a set reduces the available capacity to other destinations.  I'll
> propose some text on this shortly.
> 
> (A) does the WG want to keep the document as is or break apart the current
> document into two documents?
> 
> - the first being the credit window and generic traffic classification definition
> and the second being the DA/DSCP extension and traffic classification sub-DI
> 
> I can't speak for my co-authors, but I'm okay proceeding either way, but now
> is the time to decide.
> 
> (B) finally, does the WG want to take the notional Ethernet/PCP based traffic
> classification which was added as an appendix, see [1], to sanity check the
> current functional decomposition and make it a full blown Ethernet/PCP
> extension
> 
> I also look forward to discussing this in London (in the joint meeting with
> ccamp).
> 
> Lou
> 
> [1]

---

From: Rick Taylor <[email-masked]>
Date: Sat, 3 Mar 2018 11:09:16 +0000

(Sorry for the Outlook enforced top-post)

Lou,

I've just been diving deeper into the draft.  In general, I like it.  I like the fact it covers per DSCP credit windows as well as per-destination as with Stan's original approach.

However, when discussing a more general TCID split out, I would prefer to see the Credit Window Id removed from the TCID SDIs, so the TCID SDI's become more general purpose, and to compensate, add the TCID alongside the CID in the Credit Window Intiialization Data Item.

In my mind, this would result in a general purpose way to describe different traffic classifications (TCIDs) that could be referred to by both Credit Windowing, by associating a CID with a Destination and a TCID in its own message; and it can also be re-used by other drafts that wish to discuss TCIDs with per-flow-metrics (FIDs?) at a later date.

In summary, I think this is very close to golden, but just needs a bit of massaging by the WG to satisfy a broader set of demands.

Cheers,

Rick

> From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
> Sent: 03 March 2018 10:45
> To: Lou Berger; [email-masked]
> I'm starting to receive quite a few enquiries from industry for DLEP support
> for modem systems where different traffic classes flow via different paths to
> destinations, so called 'hub-assist' modems.  For these types of modem (an
> others) the ability to describe the metrics per-flow to a destination is
> required.
> 
> As I've mentioned before, I think there is benefit in splitting out the concept
> of Traffic Class Ids (as specified in this draft) into its own draft, including both
> the DSCP and Ethernet TOS examples, and then referring to that draft from
> this one, and also from others including 'metrics per TCID'.
> 
> > Subject: Re: [manet] I-D Action:
> > draft-ietf-manet-dlep-da-credit-extension-
> > 04.txt
> >
> > Hi,
> >
> > queues/credit windows can be shared among (disjoint) sets of
> > endpoints, that sending to one destination in a set reduces the
> > available capacity to other destinations.  I'll propose some text on this
> shortly.
> >
> > I can't speak for my co-authors, but I'm okay proceeding either way,
> > but now is the time to decide.
> >
> > >       - This included definition of a Notional Ethernet Credit
> > > Window Traffic Classification (in an appendix) as a sanity check on
> > > separation of mechanisms.  This can be removed at some point or
> > > moved to it's own document/extension.
> > >
> > > - One note, Traffic Class. Identifier (TID) was not changed as
> > > discussed at IETF 100
> > >
> > > Lou
> > >
> > >> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-cred
> > >> it-
> > extension-04
> > >>

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 3 Mar 2018 12:34:37 -0500

Rick/Lou,

I’d prefer doing it at the mic in the joint session with CCAMP. Not sure what the schedule looks like there.

I’m going to be in London; if this is an offline session, I’d like to participate. 

Regards,
Stan

Sent from my iPhone

> On Mar 3, 2018, at 5:45 AM, Rick Taylor <[email-masked]> wrote:
> 
> Hi Lou,
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 5 Mar 2018 15:50:25 -0500

Hi Rick,

Thanks for the comment, see below...

> I'm starting to receive quite a few enquiries from industry for DLEP support for modem systems where different traffic classes flow via different paths to destinations, so called 'hub-assist' modem…

I've been thinking about the case quite a bit.  Some of the degenerate 
use cases seem really complex from a representation standpoint, but my 
thinking hasn't matured enough to see an elegant solution.  So I'd be 
thrilled with *any* discussion on this topic.

> @chairs: Would you like Lou or I to grab 10 mins at the mic to talk about this, or try to work it out offline?

I think it would be really useful to hear your perspective on the 
problem and possible solutions.  In the context of the credit window 
draft, I think it's pretty trivial to say that for destinations that 
share the same CID, that data sent to one reduces the available 
bandwidth to the other destinations -- as this is what a credit window 
implies.  But the more general issue of the relationship of shared 
resources and representation of such metrics is really interesting and 
challenging.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 5 Mar 2018 15:46:16 -0500

Thanks Rick.  See below.

> In my mind, this would result in a general purpose way to describe different traffic classifications (TCIDs) that could be referred to by both Credit Windowing, by associating a CID with a Destinat…

I certainly agree with this point as a general principle, and I think 
this can be supported by the Traffic Classification (TC) Data Item .  
One thing I ran into in the specific context of credit windows,  and why 
I've kept the credit window specific TC sub item definitions 
(DiffServ/DSCP, and Ethernet/PCP, Credit Window Traffic Classification 
Sub Data Items) was how to balance the concepts consolidating 
definitions at session startup and minimizing needed processing when a 
destination is learned.

In particular, when destinations is advertised by a modem, the full set 
of {traffic classification -> Credit windows} needs to be advertised, 
and consistency validation and hardware setup/config should be minimized 
during destination up processing

In the current approach

1) definitions of credit windows (~=queues) are provided as part of 
session information

     Each Credit Window Identifier (CID) is provided by a modem in a 
Credit Window Initialization Data Item in a Session Initialization 
Response or Session Update Message.

2) definitions of valid sets of DSCPs (or PCPs) that can be used at the 
same time are provided as part of session information

     Certain sets of DSCPs/PCPs can be used at the same time.  These are 
communicated as a complete set so that it is possible to check the 
consistency of the set (e.g., so that the same value is used twice).  
The complete set is identified by a Traffic Class. Identifier (TID)

3) Different DSCPs(PCPS) map to a specific credit/window

     In addition to validating the DSCPs/PCPs that could be used at one 
time (to reach a  destination), each DSCP must be mapped to a specific 
CID.  This could be done by composting TID = listof{DSCPs-->CIDs} .  We 
choose the more compact representation of TID = list of { CID, list of 
{DSCPS} }.  This information is provided in the Traffic Classification 
Data Item as part of session information. Again this allows validation 
and, potentially queue configuration, during session init.

4) When destinations is advertised by a modem, the full set of {Credit 
window and TC} information that can be used needs to be provided

     If the full list of {DSCPs-->CIDs} mappings were provided on an Up 
message, there would be significant validation required at that time. 
Instead we provide just a list of {CIDs}.  Since the TC data item 
already provided CID->DSCPs, this is all that is needed and no CID/TID 
validation is needed.

> In summary, I think this is very close to golden, but just needs a bit of massaging by the WG to satisfy a broader set of demands.

Certainly other organizations are possible and I'm fully open to 
considering other organization of the information.

I/we did discuss some alternatives and found issues or limitations with 
these.  As such, I'd like to ask that you present any alternate approach 
on list so that it's possible to sync up at the detail level.

I also would be happy to chat off line in london about possibilities.  
Let's figure out a time and let the list know what that is so other's 
may join...

Thanks,
Lou

---

From: Rick Taylor <[email-masked]>
Date: Tue, 6 Mar 2018 13:19:48 +0000

Hi All,

I was unclear.  I meant "Chairs, would you like to reserve a slot in
the agenda so Lou and I can have a discussion at the mic about this
topic, or would you rather we kept this to the list."

If you do not have space in the agenda, I am happy to find a quiet spot
and let everyone know so we can have a DLEP-DiffServ BoF.

Cheers,

Rick

On Sat, 2018-03-03 at 12:34 -0500, Stan Ratliff wrote:
> > I'm starting to receive quite a few enquiries from industry for
> > DLEP support for modem systems where different traffic classes flow
> > via different paths to destinations, so called 'hub-assist'
> > modems.  For these types of modem (an others) the ability to
> > describe the metrics per-flow to a destination is required.
> > 
> > As I've mentioned before, I think there is benefit in splitting out
> > the concept of Traffic Class Ids (as specified in this draft) into
> > its own draft, including both the DSCP and Ethernet TOS examples,
> > and then referring to that draft from this one, and also from
> > others including 'metrics per TCID'. 
> > 
> > @chairs: Would you like Lou or I to grab 10 mins at the mic to talk
> > about this, or try to work it out offline?
> > 
> > Cheers,
> > 
> > Rick
> > 
> > > draft.  The
> > > https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-exten
> > > sion-
> > > 04#appendix-B
> > > 
> > > 
> > > > Window
> > > > discussed
> > > > > A New Internet-Draft is available from the on-line Internet-
> > > > > Drafts
> > > 
> > > directories.
> > > > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-cre
> > > > > dit-
> > > 
> > > extension/
> > > > > 
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-d
> > > > > a-credit-
> > > 
> > > extension-04
> > > > > 
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-da-cr
> > > > > edit-
> > > 
> > > extension-04
> > > > > 
> > > > > 
> > > > > Please note that it may take a couple of minutes from the
> > > > > time of
> > > 
> > > submission

---

From: Lou Berger <[email-masked]>
Date: Tue, 6 Mar 2018 08:27:53 -0500

Hi Rick,

> topic, or would you rather we kept this to the list."
I thought I understood your previous e-mails, but now you lost me.

> and let everyone know so we can have a DLEP-DiffServ BoF.
If this is the topic I think you're referring to (shared paths for 
different DSCPs/PCPs) I think it would be great to have you present some 
slides on a problem statement and for a discussion to follow. I'm also 
happy to provide input on the slides if you want.  If this is a 
different topic, can you clarify?

Thanks,
Lou

---

From: Rick Taylor <[email-masked]>
Date: Tue, 6 Mar 2018 19:24:25 +0000

Hi Lou,

I'm just making things less clear!

You are correct, the topic is shared paths for different flows, and I'd be happy to put some slides together.

Cheers,

Rick

> From: Lou Berger [mailto:[email-masked]]
> Sent: 06 March 2018 13:28
> To: Rick Taylor; [email-masked]
> Cc: [email-masked]
> > If you do not have space in the agenda, I am happy to find a quiet
> > spot and let everyone know so we can have a DLEP-DiffServ BoF.
> If this is the topic I think you're referring to (shared paths for different
> DSCPs/PCPs) I think it would be great to have you present some slides on a
> problem statement and for a discussion to follow. I'm also happy to provide
> input on the slides if you want.  If this is a different topic, can you clarify?
> 
> Thanks,
> Lou
> 
> > Cheers,
> >
> > Rick
> >
> >>> I'm starting to receive quite a few enquiries from industry for DLEP
> >>> support for modem systems where different traffic classes flow via
> >>> different paths to destinations, so called 'hub-assist'
> >>> and then referring to that draft from this one, and also from others
> >>> including 'metrics per TCID'.
> >>>
> >>>> available capacity to other destinations.  I'll propose some text
> >>>> on this shortly.
> >>>>
> >>>> - the first being the credit window and generic traffic
> >>>> classification definition and the second being the DA/DSCP
> >>>> extension and traffic classification sub-DI
> >>>>
> >>>> I can't speak for my co-authors, but I'm okay proceeding either
> >>>> way, but now is the time to decide.
> >>>>
> >>>> (B) finally, does the WG want to take the notional Ethernet/PCP
> >>>> based traffic classification which was added as an appendix, see
> >>>> [1], to sanity check the current functional decomposition and make
> >>>> it a full blown Ethernet/PCP extension
> >>>>
> >>>> my personal preference is to do this, it's not much effort and
> >>>> seems worthwhile.
> >>>>
> >>>> I also look forward to discussing this in London (in the joint
> >>>> meeting with ccamp).
> >>>>
> >>>> Lou
> >>>>
> >>>> [1]
> >>>>> Window Traffic Classification (in an appendix) as a sanity check
> >>>>> on separation of mechanisms.  This can be removed at some point or

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 7 Mar 2018 14:47:59 +0200

> I’m going to be in London; if this is an offline session, I’d like to

Even if some discuss offline, I hope we get informed about summary on this
wg-list to follow up with the wg-draft,

Thanks,

AB