Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Roland,

Thanks for the updates and the offer to reread with clarifications in
mind.  Just one more note, inline...

On Wed, Feb 20, 2019 at 11:16:10PM +0100, Roland Bless wrote:
> Hi Benjamin,
> 
> On 17.02.19 at 20:24 Benjamin Kaduk wrote:
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > This document is generally in fine shape, and has some good discussion
> > in it.  I basically just have some editorial suggestions.
> > 
> > As one general note, the text sometimes seems to present a mixed story,
> > for example in the case of "downgrading" traffic from other PHBs.  We're
> > told to in general not do this instead of dropping traffic, but on the
> > other hand an example use of the LE PHB is for downgrading traffic from
> > some other PHB (but only when it does not violate the operational
> > objectives of that other PHB).  Greater clarity on who is authorized to
> > decide to downgrade, and in what cases it makes sense, could be useful.
> 
> Ok, I'll re-read the text and try to add a bit of clarifying text.
> 
> > In a similar vein, the text sometimes suggests a dichotomy between use
> > of the LE PHB for "preemptable" traffic vs. as a "scavenger" service
> > class, and at other times suggests that these usages are identical.  But
> > those are, of course, editorial matters.
> 
> Thanks for pointing that out. I think you are right, but it
> is the very nature of the LE: it should scavenge residual capacity,
> but it must be preemptable by BE in case it needs more resources,
> so it has both facets.
> 
> 
> > Abstract
> > 
> >                                         The primary objective of this LE
> >    PHB is to protect best-effort (BE) traffic (packets forwarded with
> >    the default PHB) from LE traffic in congestion situations, i.e., when
> >    resources become scarce, best-effort traffic has precedence over LE
> >    traffic and may preempt it.  Alternatively, packets forwarded by the
> >    LE PHB can be associated with a scavenger service class, i.e., they
> >    scavenge otherwise unused resources only.  [...]
> > 
> > It seems like "preemptable" and "scavenger" are being deliberately
> > conflated, but are not necessarily the same.
> 
> The scavenger part came in somewhat late and that may have caused
> the confusion by the conflation. I'll try to clarify this a bit more.
> 
> > Section 3
> > 
> >    (e.g., if a transport connection fails due to timing out, the
> >    application may try several times to re-establish the transport
> >    connection in order to resume the application session before finally
> > 
> > There was some directorate review traffic suggesting that further
> > qualifications about the retries; I do see such qualifying statemnets in
> > the next paragraph, so maybe there is no big need to do so here as well..
> 
> Yep.
> 
> >    Use of the LE PHB might assist a network operator in moving certain
> >    kinds of traffic or users to off-peak times.  Alternatively, or in
> >    addition, packets can be designated for the LE PHB when the goal is
> >    to protect all other packet traffic from competition with the LE
> > 
> > Is it "alternatively" or "in addition" -- can it really be both at the
> > same time?  (I suppose the intent is that different operators could
> > apply different policies?)
> 
> This formulation is actually taken unchanged from the original RFC 3662,
> but I may rephrase it. I think it can be "in addition", because
> it may belong to different traffic aggregates. The background of this
> stems IMHO from the fact that in former times, some operators throttled
> or blocked peer-to-peer file sharing traffic. A better option would be
> to let users mark it as LE and simply accept it, because it does no
> harm to other traffic.
> 
> > Section 9
> > 
> > Is there a section reference in RFC 3754 to point us to?
> 
> I don't think so, because the whole RFC discusses Multicast and Diffserv.
> 
> > (Also, the RFC Editor will probably put a comma after "Basically".)
> 
> Done. :-)
> 
> >    Several forwarding error correction coding schemes such as fountain
> >    codes (e.g., [RFC5053]) allow reliable data delivery even in
> > 
> > I'm used to seeing "forward error correction"; is "forwarding error
> > correction" also an acceptabale usage?
> 
> Good catch, will use Forward Error Correction.
> 
> >    While the resource contention problem caused by multicast packet
> >    replication is also true for other Diffserv PHBs, LE forwarding is
> >    special, because often it is assumed that LE packets get only
> > 
> > nit: s/get only/only get/
> 
> Done.
> 
> >    forwarded in case of available resources at the output ports.  The
> >    previously mentioned redundancy data traffic could nicely use the
> >    varying available residual bandwidth being utilized the by LE PHB,
> >    but only if the previously specific requirements in the internal
> >    implementation of the network devices are considered.
> > 
> > I'm not sure how to interpret "previously specific requirements", here.
> > Was it intended to be "previously specified requirements"?
> 
> Ok, then I need to state that more explicitly: it refers to the
> replication condition in the preceding paragraph.

It sounds like we want the "specific requiremnets stated above", t hen.

-Benjamin

> > Section 12
> > 
> > As per the GenART review, updating the draft in missref is a bit weird,
> > but we can probably leave it to the responsible AD and RFC Editor to
> > decide whether to retain the "Updates" relationship or directly effect
> > the needed changes.
> 
> Spencer already replied to this.
> 
> Best regards,
>  Roland