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

[Gorry Fairhurst <[e-mail]>]

On 16/07/2017, 12:23, Black, David wrote:
> 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
I also don't like black-holing network traffic... but in this case I can 
still see why (b) could make sense. The thing here is that an LE 
transport needs to accept the packets it sends in the network may not 
reach the endpoint during resource congestion. Therefore, it must have 
mechanisms to deal with such lack of reception for LE packets. The case 
for LE is a little different than the other classes we have defined, for 
LE, the congestion could persist for a time - and that's quite OK if 
there is other traffic more important to use the link resource. If there 
is a deadline, an LE App could decide to elevate the LE transport 
session to BE (e.g. because LE class traffic fails to make progress), 
otherwise it can decide to defer transmssion and finally miss the 
deadline.  That leaves me open to hearing arguments for case (b).

An argument for (a) Is that bleaching to DSCP 0 (default) is common 
deployed practice. For all other traffic, this results in a lower 
class.  Indeed, the router could tell you this was happening,  I'm 
interested to know of a good way to tell the sender the DSCP has been 
remarked by a router... I'm waiting to be convinced a credible method 
exists.

An argument against (a) is that an endpoint that chooses to send traffic 
marked LE, and gets elevated to the BE class by the network, may later 
on the path encounter other traffic that was also originally marked as 
LE. That other traffic is now lower than this traffic - that's an 
argument for not "promoting" without telling the sender. Dropping 
effectively tells the LE transport there is a problem.

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