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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 04 Apr 2019 04:42:38 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-manet-dlep-pause-extension-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It is unclear to me what the purpose of the pause and resume is here?

Is it to enable the router to build the queue rather than the modem if there is
a queue buildup in the modem? If that is the case, then pause and resume will
be done frequently and on short time scales due to variability of the link. And
then the router resumes transmission to the modem when the buffer has been
reduced? As this is enabled to be done on a queue level what how does one
ensure the per hop behavior that is intended based on the DSCP with this split.
Because you will get an interaction between the two queue that are in series
for the same link which makes ensuring the PHB difficult.

I hope for a timely clarification to determine if this is a discuss or not and
make it more actionable.

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Apr 2019 11:56:50 -0400

Hi,

On 4/4/2019 7:42 AM, Magnus Westerlund via Datatracker wrote:
> a queue buildup in the modem?

Yes and also allow a router to implement more sophisticated queuing if 
it so chooses, e.g., mapping multiple DHCPs into a single modem queue.

>   If that is the case, then pause and resume will
> reduced?

Also correct.  Fundamentally this is the same as what was defined 
previously for PPPoE in RFC5578, but using a simpler on/off mechanism 
and DLEP.  DLEP is the replacement for using PPPoE for radio to router 
information.

> As this is enabled to be done on a queue level what how does one

I agree that there are two queues in series, but don't see this as 
materially different than what RFC5578 allowed or 2 routers 
interconnected over a link that supports normal Ethernet pause or PFC.  
In other words, I see that a modem that is DSCP aware must conform with 
the same requirements as a router that is DSCP aware.

At least this is my option.  Others may see it differently, e.g., Stan 
(who co-authored RFC5578 and is the doc Shepherd) or the others in the 
WG who have been working radio/router interfaces for far longer than I 
have...

Lou

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 4 Apr 2019 16:25:17 +0000

Magnus, 

Comments inline.

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, April 04, 2019 11:57 AM
> To: Magnus Westerlund <[email-masked]>; The IESG
> <[email-masked]>
> Cc: [email-masked]; [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.***
> .
> 
> Hi,
> 
> 
> 
> > Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIDaQ&c=LlUvidvlhStGUSxQl0giOA&r=QzgCKlK-
> eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=f5B7e3tVsTj3DKLKk2ezsAU_6euBSOyMidhuFkhl35E&e
> =
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmanet-2Ddlep-2Dpause-
> 2Dextension_&d=DwIDaQ&c=LlUvidvlhStGUSxQl0giOA&r=QzgCKlK-
> eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=OJ_1jy2Lby14yc9LoY16qh7InxhB-Cw1okJYs7IahBI&e=
> 
> >
> 
> >
> 
> >
> 

I'm not exactly sure what you mean here; I'm assuming it's along the lines of the radio having a congested, high-priority queue, and a non-congested, low priority queue. In  this case, the radio could theoretically allow low-priority traffic into its queue, while pausing the high-priority traffic. The concern would be a re-ordering of traffic coming out of the radio and onto the RF due to this condition. 

Along the lines of what Lou has already said, I remember something Fred Baker once told me. Paraphrasing, it was "Well, if you're going to trust the radio to carry the traffic in the first place, you should also trust it to <fill-in-the-blank>." As Lou put it, "a modem that is DSCP aware must conform with the same requirements as a router that is DSCP aware." The expectation in the above case is that the radio would do the appropriate "clever things" to keep the traffic prioritization intact while resolving the congestion.

The main impetus behind the document is to minimize the number of dropped packets for any given DSCP bucket, as the router (usually) has more memory and thus, larger queue depth. 

Regards,
Stan

> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_manet&d=DwIDaQ&c=LlUvidvlhStGUS
> xQl0giOA&r=QzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=3Ub6LUgC3pFuA3vS1o3azzxUkeG8boLU9YtaifWr6uM
> &e=
> 
> >

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 5 Apr 2019 09:11:57 +0000

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.

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?

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?

Cheers

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: Thu, 11 Apr 2019 07:47:32 -0400

Magnus,

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

> information so that lower latency or more deterministic behavior can be

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.

> there need to be some applicability statement here due the limitations

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Apr 2019 12:12:05 +0000

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

-- 

Magnus Westerlund