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

From: Lou Berger <[email-masked]>
Date: Sun, 5 May 2019 20:40:04 -0400

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 May 2019 07:56:26 +0000

Thanks Lou,

I think that clarifies my issue. I will clear with the assumption that
you will include this.

Thanks

Magnus

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Lou Berger <[email-masked]>
Date: Mon, 6 May 2019 06:49:13 -0400

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

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 6 May 2019 15:08:47 +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:[email-masked]]
> Sent: Monday, May 06, 2019 6:49 AM
> To: Magnus Westerlund <[email-masked]>; Ratliff,
> Stanley <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Bob
> Briscoe <[email-masked]>; [email-masked]
> 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.***
> 
> >> 	I've updated the intro to try to address your points, while also
> >> trying to bring in Stan's point, :
> >>
> >>> 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
> >>>
> >>>>> 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.
> >>>>> 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.
> >>>>
> >>>>
> >>>>> 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?
> >>>> 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.