Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02)

["Black, David" <[e-mail]>]

Small comment as an individual on Roland's original message in this thread:

> >> LE-strict: should not be promoted to BE. Now we have two cases:
> >>           a) DS domain remarks to BE and passes it as BE to the next DS
> >>              domain. The receiver could probably use some feedback
> >>              channel to let the sender know that this remarking
> >>              happened.
> >>              An appropriate reaction should be left to the application
> >>              then (continue, abort, use LE transport protocol,
> >>              rate limit, etc.) => E2E principle.
> >>           b) DS domain simply drops the LE packet.
> >>
> >> I think b) is not useful.

I strongly agree that b) is a bad idea.  We should not be adding new ways to black-hole network traffic...

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Tim Chown
> Sent: Thursday, July 13, 2017 11:02 AM
> To: Brian E Carpenter <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02)
> 
> Hi,
> 
> > On 13 Jul 2017, at 02:29, Brian E Carpenter <[e-mail]>
> wrote:
> >
> >> So a useful strategy would be to always remark CS1 to LE, when
> >> CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1.
> >
> > Yes, but I think it's better called a heuristic, not a strategy.
> > Any solution that does not involve an explicit agreement between
> > two neighbouring domains is really a "best guess".
> >
> > We could also say that a useful heuristic would be to always
> > leave CS1 as it is, if CS1 was *not* previously known to be used
> > for LE at that interface. Or alternatively, bleach it to CS0.
> > If you don't definitively know the policy of the domain that
> > forwards a packet to you, whatever you do is a guess. If you
> > do know that policy, you can do the right thing.
> 
> That sounds fair enough.
> 
> When LBE was being tested years ago on GEANT and various NRENs, we did
> also agree as “consenting networks” that CS1 (as then) would not be
> bleached, so there was DSCP transparency for participating networks, even if
> not all the elements were implementing the queuing prioritisation.
> 
> Tim
> 
> >
> > Regards
> >   Brian
> >
> > On 13/07/2017 00:46, Bless, Roland (TM) wrote:
> >> Hi,
> >>
> >> In
> https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9tBx
> 4
> >> David made the comment:
> >>> ****I definitely want to see broader WG discussion of that “MUST
> remark” requirement, as it’s not backwards compatible with RFC 4594 - at a
> minimum, some thought should be applied to transition and mixing networks
> that use CS1 and the new LE DSCP.
> >>
> >> Here are some general thoughts on remarking of the LE PHB.
> >>
> >> If correctly implemented LE (lower effort) traffic will not harm BE
> >> (best-effort) traffic, because BE traffic will preempt LE traffic.
> >> DiffServ Domains that are not implementing LE may carry LE traffic
> >> within their BE aggregate. They must be aware, however, that the
> >> "no harm" property of LE is not given.
> >>
> >> There are now two types of LE users:
> >> LE-min: this user does not care if LE packet experience better
> >> forwarding treatment, so promoting them to BE is ok.
> >>
> >> LE-strict: this user wants to be sure that LE is obeying the
> >> "no harm" property, i.e., only otherwise unused resources
> >> should be consumed by LE traffic.
> >>
> >> The question is now, how the LE-strict user can detect whether
> >> the packets were promoted to BE. Let's assume we have two
> >> different DSCPs LE-min and LE-strict. Then:
> >> LE-min: can be promoted to BE, but should stay marked as LE-min
> >>        to let subsequent domains handle it correctly as LE traffic
> >> LE-strict: should not be promoted to BE. Now we have two cases:
> >>           a) DS domain remarks to BE and passes it as BE to the next DS
> >>              domain. The receiver could probably use some feedback
> >>              channel to let the sender know that this remarking
> >>              happened.
> >>              An appropriate reaction should be left to the application
> >>              then (continue, abort, use LE transport protocol,
> >>              rate limit, etc.) => E2E principle.
> >>           b) DS domain simply drops the LE packet.
> >>
> >> I think b) is not useful.
> >>
> >> Coming back to the question above:
> >> A DS domain must be able to map DSCP to PHB freely (see RFC 2474).
> >> So if a DS domain currently supports LE and uses the CS1 DSCP for that,
> >> it should support the new LE DSCP, too.
> >> The current draft says
> >>   A DS domain that still uses DSCP CS1 for marking LE traffic
> >>   (including Low Priority-Data as defined in [RFC4594] or the old
> >>   definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010'
> >>   at the egress to the next DS domain.  This increases the probability
> >>   that the DSCP is preserved end-to-end, whereas a CS1 marked packet
> >>   may be remarked by the default DSCP if the next domain is applying
> >>   DiffServ-intercon [RFC8100].
> >>
> >> So a useful strategy would be to always remark CS1 to LE, when
> >> CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1.
> >> More input welcome.
> >>
> >> Regards,
> >> Roland
> >>
> >>
> >