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

["Ratliff, Stanley" <[e-mail]>]

Magnus, 

Comments inline.

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Thursday, April 04, 2019 11:57 AM
> To: Magnus Westerlund <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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,
> 
> 
> 
> On 4/4/2019 7:42 AM, Magnus Westerlund via Datatracker wrote:
> 
> > 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://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
> =
> 
> > for more information about IESG DISCUSS and COMMENT positions.
> 
> >
> 
> >
> 
> > The document, along with other ballot positions, can be found here:
> 
> > 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=
> 
> >
> 
> >
> 
> >
> 
> > ----------------------------------------------------------------------
> 
> > 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?
> 
> 
> 
> 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
> 
> > 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?
> 
> 
> 
> 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
> 
> > 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'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

> 
> 
> 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
> 
> 
> 
> > I hope for a timely clarification to determine if this is a discuss or not and
> 
> > make it more actionable.
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > _______________________________________________
> 
> > manet mailing list
> 
> > [e-mail]
> 
> > 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.