Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)

"Ratliff, Stanley" <sratliff@idirect.net> Mon, 06 May 2019 15:08 UTC

Return-Path: <sratliff@idirect.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E241F1201B4 for <manet@ietfa.amsl.com>; Mon, 6 May 2019 08:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6hFhl-eaZma for <manet@ietfa.amsl.com>; Mon, 6 May 2019 08:08:52 -0700 (PDT)
Received: from us-smtp-delivery-174.mimecast.com (us-smtp-delivery-174.mimecast.com [63.128.21.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7F31201A8 for <manet@ietf.org>; Mon, 6 May 2019 08:08:52 -0700 (PDT)
Received: from webmail.idirect.net (198.180.159.2 [198.180.159.2]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-258-jk-iWV4_NCG1k_fDuoeWHA-1; Mon, 06 May 2019 11:08:47 -0400
Received: from vausditchmc3.idirect.net (10.250.251.203) by vausditchmc3.idirect.net (10.250.251.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 6 May 2019 11:08:47 -0400
Received: from vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51]) by vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51%13]) with mapi id 15.01.1713.004; Mon, 6 May 2019 11:08:47 -0400
From: "Ratliff, Stanley" <sratliff@idirect.net>
To: Lou Berger <lberger@labn.net>, Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-manet-dlep-pause-extension@ietf.org" <draft-ietf-manet-dlep-pause-extension@ietf.org>, "manet@ietf.org" <manet@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, "manet-chairs@ietf.org" <manet-chairs@ietf.org>
Thread-Topic: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)
Thread-Index: AQHU6tuDcoy41n6e4kuNlesEyZ+fpKZeYAaAgAAFMPA=
Date: Mon, 6 May 2019 15:08:47 +0000
Message-ID: <0fac9fb26cd44a8e8b14b5e394ec6824@idirect.net>
References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> <bcd469e9-2d36-3fc7-0d41-56d26bb32aca@labn.net> <8c18420b622f405eb0d4adcf844b315d@idirect.net> <HE1PR0701MB25225A4933D7C72B7B19FB1895510@HE1PR0701MB2522.eurprd07.prod.outlook.com> <36cb484b-f2a5-0f13-5210-e0b67b4a4231@labn.net> <HE1PR0701MB2522FFFAC71265215BB63346952F0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <116fd2c7-2175-ffa8-d51d-25dabf5ca429@labn.net> <HE1PR0701MB2522441A2CC6524B41EF88E395300@HE1PR0701MB2522.eurprd07.prod.outlook.com> <0caf7d03-c751-4cbc-2506-99ff95d4dbc2@labn.net>
In-Reply-To: <0caf7d03-c751-4cbc-2506-99ff95d4dbc2@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.250.251.20]
MIME-Version: 1.0
X-MC-Unique: jk-iWV4_NCG1k_fDuoeWHA-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="MCBoundary=_11905061108482911"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/wZxlR-zKBCDSR0GKwN68uGjbvKk>
Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 15:08:56 -0000

Lou, 

Yup, you assumed correctly. Thanks for all of your hard work. And thank you, Magnus, for making the draft better. 

Regards,
Stan

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Monday, May 06, 2019 6:49 AM
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>om>; Ratliff,
> Stanley <sratliff@idirect.net>et>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-manet-dlep-pause-extension@ietf.org; manet@ietf.org; Bob
> Briscoe <ietf@bobbriscoe.net>et>; manet-chairs@ietf.org
> Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-
> pause-extension-06: (with DISCUSS)
> 
> ***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE VT IDIRECT.***
> 
> Thanks Magnus.   I'll upload a rev with the change today (was waiting on
> AD/Shepherd, but now assume they will ask for the upload)...
> 
> Lou
> 
> On 5/6/2019 3:56 AM, Magnus Westerlund wrote:
> > Thanks Lou,
> >
> > I think that clarifies my issue. I will clear with the assumption that
> > you will include this.
> >
> > Thanks
> >
> > Magnus
> >
> > On 2019-05-06 02:40, Lou Berger wrote:
> >> Hi Magnus/Bob,
> >> 	I've updated the intro to try to address your points, while also
> >> trying to bring in Stan's point, :
> >>
> >>     The base DLEP specification does not include any data plane flow
> >>     control capability.  The extension defined in this document supports
> >>     flow control of data traffic based on explicit messages sent via DLEP
> >>     by a modem to indicate when a router should hold off sending traffic,
> >>     and when it should resume.  This functionality parallels the flow
> >>     control mechanism found in PPP over Ethernet (PPPoE) per [RFC5578].
> >>     The extension also optionally supports DSCP (differentiated services
> >>     codepoint) aware flow control for use by DiffServ-aware modems.  (For
> >>     general background on Differentiated Services see [RFC2475].)  This
> >>     functionality is very similar to that provided by Ethernet Priority
> >>     flow control, see [IEEE.802.1Q_2014].  The extension defined in this
> >>     document is referred to as "Control Plane Based Pause".  Other flow
> >>     control methods are possible with DLEP, e.g., see
> >>     [I-D.ietf-manet-dlep-da-credit-extension] and
> >>     [I-D.ietf-manet-dlep-credit-flow-control].
> >>
> >> Please let me/us know what you think.
> >>
> >> Lou
> >>
> >>
> >> On 4/11/19 8:12 AM, Magnus Westerlund wrote:
> >>> Hi,
> >>>
> >>> I don't have a text proposal. I think if you work with Bob to detail
> >>> out the use case and clarifications on the limitations with the
> >>> protocol that should solve my issue here.
> >>>
> >>> Cheers
> >>>
> >>> Magnus
> >>>
> >>> On 2019-04-11 13:47, Lou Berger wrote:
> >>>> Magnus,
> >>>>
> >>>> On 4/5/2019 5:11 AM, Magnus Westerlund wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Thanks for the replies.
> >>>>>
> >>>>> I think the main point here is if one should treat router + modem
> >>>>> as one common queue when it comes to meeting PHBs or treat them
> as
> >>>>> two in sequence queues. If one treat them as two queues then you
> >>>>> get the same behavior as two routers in sequence. And that is
> >>>>> acceptable from one angle, but it also results in additional jitter and
> latencies.
> >>>> I think Stan's response already covered the above. From my
> >>>> perspective, I agree with stan that a modem that reports DSCPs
> >>>> should be expected to honor them like any other transit IP device
> (router, middlebox, etc.).
> >>>> I think that the following is possible in the non-diffserv modem
> >>>> aware case - but another approach would be to not deploy such
> >>>> limited modems in a network that requires DSCP support - just like
> >>>> you wouldn't deploy a router that doesn't support a particular PHB
> >>>> in network that expects to support it.
> >>>>
> >>>>> If we take the Expedited Forwarding PHB (RFC 3246) treating this
> >>>>> as two queue results in that the error is E_a1 (router) + E_a2
> >>>>> (mode) rather than a E_a for the combined queue. The question is
> >>>>> if E_a actually will be smaller than E_a1+E_a2 when one uses this
> >>>>> type of control? In the combined case if the modem queue is so
> >>>>> shallow that E_a2 << E_a1 as well as that time for performing the
> >>>>> DLEP signalling is so short that the main variations ends up being
> >>>>> in the router queue where one can apply suitable policies to
> >>>>> control queue load to prevent violation of the targets.
> >>>>> I think my main concern will be what happens if one attempts to
> >>>>> implement L4S dual queues or DETNET and have DLEP in the path.
> >>>>> Will this require additional extensions to provide more detailed
> >>>>> flow control information so that lower latency or more
> >>>>> deterministic behavior can be achieved?
> >>>> Quite likely -- I think this is not the flow control you'd want
> >>>> with DetNet (I can't speak to L4S), i'd personally use something
> >>>> like what's covered in ietf-manet-dlep-da-credit-extension.
> >>>>
> >>>>
> >>>>> I noticed that TSVART reviewer Bob Briscoe asked for a use case
> >>>>> description of the case when the main queue is pushed to the
> >>>>> router. I think that appears to be a good idea. I think what I am
> >>>>> wondering is if there need to be some applicability statement here
> >>>>> due the limitations of the technology?
> >>>> I certainly have no objection to such, particularly given
> >>>> ietf-manet-dlep-da-credit-extension.  If you have any suggested
> >>>> text, that would be helpful.  Otherwise, as I mentioned in response
> >>>> to Bob, if really needed I can work with the Shepherd/WG on some
> applicability text.
> >>>>
> >>>> Lou
> >>>>
> >>>>> Cheers
> >>>>>
> >>>>> Magnus
> >>>>>
> >>>>>

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.