Subject: [tsvwg] Interaction between L4S and tunnel-congestion-feedback

From: Bob Briscoe <[email-masked]>
Date: Fri, 22 Jul 2016 09:31:04 +0100

Chairs, list,

The draft-ietf-tsvwg-tunnel-congestion-feedback-02 draft says

    Faked ECN-capable transport (ECT) is used at ingress to defer packet
    loss to egress. [...]

Given L4S, I think we just need to make sure a tunnel ingress solely 
sets Not-ECT packets to ECT(0), not ECT(1).

I'll think about it further to check all the possible interactions with 
other RFCs and L4S, but I think that's all.

Cheers

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: <[email-masked]>
Date: Fri, 22 Jul 2016 08:46:51 +0000

Hi David, hi Gorry,

I'd like to ask you to clarify for me, whether putting draft-ietf-tsvwg-ieee-802-11 on standards track will make DSCP 001 000 the standard DSCP for Scavenger/Less than best Effort. The document would then be the first normative fixing this.

I prefer a DSCO 000 xyz to identify Scavenger/LBE, as proposed by draft-bless-tsvwg-le-phb.

I hope there's an easy way out, helping the supporters of draft-ietf-tsvwg-ieee-802-11 and me.

I got no objections against draft-ietf-tsvwg-ieee-802-11 and no other objections against putting it on standards track. 

Regards,

Ruediger

---

From: "Black, David" <[email-masked]>
Date: Mon, 25 Jul 2016 21:56:11 +0000

Hi Ruediger,

<WG CHAIR HAT OFF>

> I'd like to ask you to clarify for me, whether putting draft-ietf-tsvwg-ieee-802-11
> on standards track will make DSCP 001 000 the standard DSCP for Scavenger/Less
> than best Effort. The document would then be the first normative fixing this.

I don't think it does that, but this is a long story, and I'm writing this note as an
individual to encourage WG discussion.  As has been previously recounted on this
list, the history of Scavenger/Lower Effort service has been neither pretty nor
straightforward.

RFC 3662 is Informational and as part of defining Lower Effort service, "suggested"
use of CS1 as one of a number of possible DSCPs for Lower Effort (one of the AF
PHBs was another suggestion).

RFC 4594 specified CS1 as the recommended DSCP for Low Priority Data.  This is where
things get interesting, as while RFC 4594 is officially an Informational RFC, it is in
practice used as if it were a Best Current Practice RFC.  Moreover, RFC 4594 used
RFC 2119 language (RECOMMENDED) to specify use of CS1 for Lower Effort.

To the extent that you're looking for the first "normative" document that specifies
use  of CS1 for lower effort service, that document is (in practice) RFC 4594.

More recently:
	- RFC 7567 discusses use of CS1 for Lower Effort traffic, and warns of
		pitfalls and problems in doing so.  RFC 7657 is Informational.
	- draft-ietf-tsvwg-rtcweb-qos specifies use of CS1 for Lower Effort data
		(for WebRTC). This draft is IESG-approved to become a
		standards-track RFC, and is currently being held to resolve
		an unrelated WebRTC issue (which I think was  worked out this
		past week). 
	- draft-ietf-tsvwg-ieee-802-11 repeats RFC 4594's usage of CS1 for Lower
		Effort (citing RFC 4594), as part of using RFC 4594 service classes
		as the source for DSCP to 802.11 QoS mappings.

So the pedantic answer to your question is that at least draft-ietf-tsvwg-rtcweb-qos
got there first (standards track document that specifies use of CS1 for Lower Effort traffic).

The actual (useful)  answer is that RFC 4594 is the primary reference for this use of CS1.

> I prefer a DSCP 000 xyz to identify Scavenger/LBE, as proposed by draft-bless-
> tsvwg-le-phb.
> 

I'm sure there's a way out, but it doesn't look easy from here ...

I think we have to assume that there are deployments of CS1 for Lower Effort
service, and hence draft-bless-tsvwg-le-phb will need to deal with existing usage
of CS1, and also probably needs to update RFC 4594.

Still speaking only for myself, I hesitate to just switch out Lower Effort  use of CS1
for an 000 xyz DSCP - the situation appears to be more complicated. 

</WG CHAIR HAT OFF>

I will say one thing as WG chair - I hesitate to hold QoS mapping drafts like
draft-ietf-tsvwg-rtcweb-qos and draft-ietf-tsvwg-ieee-802-11 for possible
replacement of CS1 by a not-currently-deployed DSCP, as these drafts are
intended to map to/from what networks actually do.

Thanks, --David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 22, 2016 4:47 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]
> Subject: Status of CS1 if draft-ietf-tsvwg-ieee-802-11 is put on Standards Track
> 
> Hi David, hi Gorry,
> 
> I'd like to ask you to clarify for me, whether putting draft-ietf-tsvwg-ieee-802-11
> on standards track will make DSCP 001 000 the standard DSCP for Scavenger/Less
> than best Effort. The document would then be the first normative fixing this.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2016 11:57:51 +1200

Hi David,

> <WG CHAIR HAT OFF>
...
> for an 000 xyz DSCP - the situation appears to be more complicated.

It is more complicated, but we shouldn't ignore the fact the using the code
point that is standardised for the CS1 behaviour by RFC 2474 for another
purpose is clearly a violation of RFC 2474. The CSx code points are *not*
made available for locally defined usage by RFC 2474, unlike all other
code points. It's been wrong from the start and I greatly regret not having
made a big fuss when RFC 3662 was drafted.

> intended to map to/from what networks actually do.

Yes, we have to take account of running code, but I suspect that only a small
minority of networks treat DSCP 001000 as LE in violation of RFC 2474. There
is no doubt another minority that treat it correctly as CS1, and a large
majority that either bleach it or ignore it. So let's not exagerrate the
operational problem.

>> I prefer a DSCO 000 xyz to identify Scavenger/LBE, as proposed by draft-bless-

I fully agree. We should IMHO advance that work as quickly as possible, and
of course include "Updates:" text for any contradictory RFCs that get
published first.

Regards
    Brian

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 06:33:03 +0000

Hi David,

it is fair and good practice to allow for usage or migration of CS1 to another DSCP for LBE (should agreement be reached on such a different LBE codepoint).

RFC4594 RECOMMENDs more related to LBE/Low-Priority Data (page 21):

      In network segments that use IP precedence marking, only one of
      the two service classes can be supported, High-Throughput Data or
      Low-Priority Data.  We RECOMMEND that the DSCP value(s) of the
      unsupported service class be changed to 000xx1 on ingress and
      changed back to original value(s) on egress of the network segment
      that uses precedence marking.  For example, if Low-Priority Data
      is mapped to Standard service class, then 000001 DSCP marking MAY
      be used to distinguish it from Standard marked packets on egress.

And as you mentioned in your email (RFC4594 page 49):

      The RECOMMENDED [RG: Low-Priority Data] DSCP marking is 
      CS1 (Class Selector 1).

It looks as if most aspects are mentioned by RFC4594, CS1, a 000 xyz codepoint (and even network providers classifying and marking ranges of DSCPs rather than single ones, called IP-Precedence above). If DiffServ Intercon was applied, the sending network adapts the DSCP at an Interconnection (the MAY...egress above seems to say that too). 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Black, David [mailto:[email-masked]] 
Gesendet: Montag, 25. Juli 2016 23:56
An: Geib, Rüdiger; [email-masked]
Cc: [email-masked]
Betreff: RE: Status of CS1 if draft-ietf-tsvwg-ieee-802-11 is put on Standards Track

Hi Ruediger,

<WG CHAIR HAT OFF>

> I'd like to ask you to clarify for me, whether putting 
> draft-ietf-tsvwg-ieee-802-11 on standards track will make DSCP 001 000 
> the standard DSCP for Scavenger/Less than best Effort. The document would then be the first normative fixing this.

I don't think it does that, but this is a long story, and I'm writing this note as an individual to encourage WG discussion.  As has been previously recounted on this list, the history of Scavenger/Lower Effort service has been neither pretty nor straightforward.

RFC 3662 is Informational and as part of defining Lower Effort service, "suggested"
use of CS1 as one of a number of possible DSCPs for Lower Effort (one of the AF PHBs was another suggestion).

RFC 4594 specified CS1 as the recommended DSCP for Low Priority Data.  This is where things get interesting, as while RFC 4594 is officially an Informational RFC, it is in practice used as if it were a Best Current Practice RFC.  Moreover, RFC 4594 used RFC 2119 language (RECOMMENDED) to specify use of CS1 for Lower Effort.

To the extent that you're looking for the first "normative" document that specifies use  of CS1 for lower effort service, that document is (in practice) RFC 4594.

More recently:

So the pedantic answer to your question is that at least draft-ietf-tsvwg-rtcweb-qos got there first (standards track document that specifies use of CS1 for Lower Effort traffic).

> I prefer a DSCP 000 xyz to identify Scavenger/LBE, as proposed by 
> draft-bless- tsvwg-le-phb.
> 
> I hope there's an easy way out, helping the supporters of 
> draft-ietf-tsvwg-ieee-
> 802-11 and me.

I think we have to assume that there are deployments of CS1 for Lower Effort service, and hence draft-bless-tsvwg-le-phb will need to deal with existing usage of CS1, and also probably needs to update RFC 4594.

Still speaking only for myself, I hesitate to just switch out Lower Effort  use of CS1 for an 000 xyz DSCP - the situation appears to be more complicated. 

</WG CHAIR HAT OFF>

I will say one thing as WG chair - I hesitate to hold QoS mapping drafts like draft-ietf-tsvwg-rtcweb-qos and draft-ietf-tsvwg-ieee-802-11 for possible replacement of CS1 by a not-currently-deployed DSCP, as these drafts are intended to map to/from what networks actually do.

Thanks, --David

> I'd like to ask you to clarify for me, whether putting 
> draft-ietf-tsvwg-ieee-802-11 on standards track will make DSCP 001 000 
> the standard DSCP for Scavenger/Less than best Effort. The document would then be the first normative fixing this.
> 
> I prefer a DSCO 000 xyz to identify Scavenger/LBE, as proposed by 
> draft-bless- tsvwg-le-phb.
> 
> I hope there's an easy way out, helping the supporters of 
> draft-ietf-tsvwg-ieee-
> 802-11 and me.
> 
> I got no objections against draft-ietf-tsvwg-ieee-802-11 and no other 
> objections against putting it on standards track.
> 
> Regards,
> 
> Ruediger