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

[Brian E Carpenter <[e-mail]>]

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

Regards
   Brian

On 13/07/2017 00:46, Bless, Roland (TM) wrote:
> Hi,
> 
> In https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9tBx4
> 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
> 
>