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

[Lou Berger <[e-mail]>]

Thanks Rick.  See below.


On 3/3/2018 6:09 AM, Rick Taylor wrote:
> (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.
>

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


>
> Cheers,
>
> Rick
>
>> -----Original Message-----
>> From: manet [mailto:[e-mail]] On Behalf Of Rick Taylor
>> Sent: 03 March 2018 10:45
>> To: Lou Berger; [e-mail]
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-
>> 04.txt
>>
>> 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:[e-mail]] On Behalf Of Lou Berger
>>> Sent: 02 March 2018 22:47
>>> To: [e-mail]
>>> Subject: Re: [manet] I-D Action:
>>> draft-ietf-manet-dlep-da-credit-extension-
>>> 04.txt
>>>
>>> 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
>>>
>>>
>>> On 3/1/2018 6:03 PM, Lou Berger wrote:
>>>> 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, [e-mail] wrote:
>>>>> 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-extensi
>>>>> on-04
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-da-cred
>>>>> it-
>>> 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/
>>>>>
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet