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

[Lou Berger <[e-mail]>]

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