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

Lou Berger <lberger@labn.net> Mon, 06 May 2019 00:40 UTC

Return-Path: <lberger@labn.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 E60771200F7 for <manet@ietfa.amsl.com>; Sun, 5 May 2019 17:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 2-zpHwO-M6l7 for <manet@ietfa.amsl.com>; Sun, 5 May 2019 17:40:10 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3396120041 for <manet@ietf.org>; Sun, 5 May 2019 17:40:09 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 592241E0721 for <manet@ietf.org>; Sun, 5 May 2019 18:40:06 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NRfqhAIvKVLCbNRfqhaD4S; Sun, 05 May 2019 18:40:06 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1q4I8uCBIa3Ol5/0n6mH3CXLIwS1QSLgK4TbONJ4XAw=; b=un11AiYTUIBcf+GJgBGHKLHwO5 0wIJjeHGOrc8t7KQzivA+VRLfluBKKqgVCoUFQWNQ3e2icPjYLuYfEGpLlKtQmKrX5oq/FhxynG4s /8fFP21dM65zepikBIU2l+6AN;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:51474 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hNRfp-001xXr-Sm; Sun, 05 May 2019 18:40:05 -0600
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Ratliff, Stanley" <sratliff@idirect.net>, 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>, "manet-chairs@ietf.org" <manet-chairs@ietf.org>, Bob Briscoe <ietf@bobbriscoe.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>
From: Lou Berger <lberger@labn.net>
Openpgp: preference=signencrypt
Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU=
Message-ID: <116fd2c7-2175-ffa8-d51d-25dabf5ca429@labn.net>
Date: Sun, 5 May 2019 20:40:04 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB2522FFFAC71265215BB63346952F0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hNRfp-001xXr-Sm
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:51474
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/Bkf9mttafw246n8jueWR2BAgnvU>
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 00:40:12 -0000

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