Subject: [tsvwg] Comments on draft-ietf-tsvwg-diffserv-intercon-05

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 May 2016 15:05:59 +0100

I have read:

https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-05

One major comment on the recommendations:

I know the inclusion of a new class for LBE was discussed, and has not 
been taken forward, the recommendation  seems broken in the current text:

         / RFC 4594

            Low-priority data may be forwarded by a Lower Effort PHB in

            one domain (like the PHB proposed by Informational

            [RFC3662]), but is remarked with DSCP CS0 at a Diffserv-

            Intercon network interconnection./

- My concern is that there may have significant implications if you 
follow this approach to the future deployability of the Lower Effort 
PHB, if there is a significant proportion of this low priority traffic, 
or that traffic that relies upon this DSCP to protect other traffic from 
collateral damage will then result in sharing the network capacity with 
the default class.

- It could for instance be OK to say that this document does not define 
specific techniques to support a Lower Effort PHB, therefore the method 
provided by this recommendation would result in this being mapped 
remarked with DSCP CS0 at a Diffserv-Intercon network interconnection. 
However, if this is the approach taken by the WG, I think it then needs 
to state the ways in which this can be a problem to LBE traffic. Perhaps 
(?) it could possibly conclude that this is not worse than being done at 
present?

----
I also have a number of language comments on the present ID:

/This draft proposes a set of common Diffserv QoS classes (Per Hop 
Behaviors/

- This is not really useful for an RFC, can you replace /draft/ by 
/document/?

- Is it still that you wish the document to "propose" these or to 
"standardise" these, both may be acceptable, but

I think proposed is fine for an informational document, should you wish 
this, but later you explicitly used the term "standard set".

/with the same DSCPs that it was received with,/

-could be better as:

/with the DSCP value with which it was received,/

/Diffserv-Intercon supports the Short Pipe model./

- The previous para appears to state this model is used, please delete 
or replace the sentence.

/Diffserv-Intercon may be also be/

- I think should be:

/Diffserv-Intercon may also be/

/not applicable to the to the.  Uniform tunneling/

- please remove extra ".".

Section 1.2 Applicability Statement

In section 1 the text said:

   "Diffserv-Intercon may be also be

    applied to the Pipe tunneling model [RFC2983], [RFC3270], but is not

    applicable to the.  Uniform tunneling model [RFC2983], [RFC3270]."

- I'm not sure why this is stated there - I'd have expected this to be 
moved to section 1.3, where it seems it may hekp explian the applicability?

/Short Pipe tunnel model for Diffserv Tunnels [RFC3270], as effective/

- could be easier to read as:

/Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because effective/

/edge-to-edge ./

- please remove extra space before ".".

/This draft proposes a standard interconnection set of 4 Treatment/

- see earlier note from me change /draft/document/ -  remove proposes  - 
is standards OK?  or not?

/her internal scheme/

- suggest change to:

/their internal scheme/

   /The set of DSCPs and PHBs supported across the

    two interconnected domains and the treatment of PHBs and DSCPs not

    recognized by the receiving domain should be part of the interconnect

    SLA./

- should this be:

   /The interconnect SLA define the set of DSCPs and PHBs supported 
across the

    two interconnected domains and the treatment of PHBs and DSCPs that

    are nor recognized by the receiving domain./

/   Similar approaches to use of a small number of traffic aggregates/

- should this be:

/   Similar approaches that also use a small number of traffic aggregates/

/DSCP 101100, see [RFC3246] , [RFC4594][RFC5865]./

- spacing seems wrong, should it be:

/DSCP 101100 (see [RFC3246], [RFC4594] and [RFC5865])./

/ the sense of RFC 4594.  [RFC4594]/

- should be:

/ the sense of [RFC4594]./

/Real Time

            Treatment Aggregate, that consume significant bandwidth,

            namely Broadcast Video, Real-Time Interactive and Multimedia

            Conferencing. /

- is namely the correct word... I wonder if these are specific known 
examples, rather than the only

permitted uses. Would /namely/ be ok as /for example/

/ If need for three-color marked Multimedia

            Conferencing traffic arises, AF42 and AF43 PHBs may be added./

- could be better as:

/ The AF42 and AF43 PHBs could be added if there is a need for 
three-color marked Multimedia

            Conferencing traffic./

/This example assumes taht all providers use their own/

- change /taht/ to /that/.

/This impacts the number of PHBs and

    DSCPs that a network provider can reasonably support ./

- please remove extra space before ".".

In the first line of figure 2, it appears that the vertical line may be 
displaced.

Gorry

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 May 2016 08:53:14 +1200

Hi Gorry,

On 17/05/2016 02:05, Gorry Fairhurst wrote:
> I know the inclusion of a new class for LBE was discussed, and has not been taken forward, the recommendation  seems broken in
> the current text:
> 
>         / RFC 4594
> 
> - My concern is that there may have significant implications if you follow this approach to the future deployability of the
> Lower Effort PHB, if there is a significant proportion of this low priority traffic, or that traffic that relies upon this DSCP
> to protect other traffic from collateral damage will then result in sharing the network capacity with the default class.

Do you have a better suggestion? As far as I can see, the *least* damage you
can do when re-marking LE traffic is to mark it as default. In the real world,
that's how "LE" traffic travels today anyway, since LE is not significantly
deployed afaik.

Certainly, re-marking LE as default is clearly better than leaving it marked
with the code point that is standardised as CS1, if the LE-supporting
network is using that code point as suggested by RFC 3662. In a network that
implements RFC 2474, that would result in the "LE" traffic receiving better
treatment than default.

> 
> - It could for instance be OK to say that this document does not define specific techniques to support a Lower Effort PHB,
> therefore the method provided by this recommendation would result in this being mapped remarked with DSCP CS0 at a
> Diffserv-Intercon network interconnection. However, if this is the approach taken by the WG, I think it then needs to state the
> ways in which this can be a problem to LBE traffic. Perhaps (?) it could possibly conclude that this is not worse than being
> done at present?
> 

The problem here is that RFC 3662 is broken. I've never been very comfortable with the
whole LE concept, and I think that the suggestion of using the codepoint standardised
for CS1 was broken from the start. I don't think any of the document that talk about
LE can be fixed properly unless we fix 3662.

Regards
     Brian

---

From: <[email-masked]>
Date: Wed, 18 May 2016 08:47:25 +0200

Hi Gorry, hi Brian,

diffserv-intercon contains text on the treatment of network management traffic marked by CS 6. Three scenarios are discussed for traffic, whose PHB is not covered by DiffServ-Intercon:

- it may be supposed to be transported by the same PHB within both 
  interconnected networks.

- the receiving network does not classify it for the same PHB 
  as the sending network, but both agree on an alternate PHB 
  supported by the receiving network. 

- there's no agreement between both networks and the receiving 
  domain applies a default treatment (an option is to 
  remark to default). 

I tried to generalize the CS 6 treatment, applicable details are missing.

If such a generalized statement is more useful, than a detailed discussion of network management, LBE and other future PHBs, should it become part of the text? Detailed guidance on network management and LBE may still remain in the document.

The default treatment of DiffServ codepoints should be part of a DiffServ-Intercon agreement. If the latter statement is stated in a contract formula here, rather than a technical statement, I'd be happy, if a suitable technical statement could be suggested on the list. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Dienstag, 17. Mai 2016 22:53
An: [email-masked]; [email-masked]
Betreff: Re: [tsvwg] Comments on draft-ietf-tsvwg-diffserv-intercon-05

Hi Gorry,

On 17/05/2016 02:05, Gorry Fairhurst wrote:
> PHB, if there is a significant proportion of this low priority traffic, or that traffic that relies upon this DSCP to protect other traffic from collateral damage will then result in sharing the network capacity with the default class.

Do you have a better suggestion? As far as I can see, the *least* damage you can do when re-marking LE traffic is to mark it as default. In the real world, that's how "LE" traffic travels today anyway, since LE is not significantly deployed afaik.

Certainly, re-marking LE as default is clearly better than leaving it marked with the code point that is standardised as CS1, if the LE-supporting network is using that code point as suggested by RFC 3662. In a network that implements RFC 2474, that would result in the "LE" traffic receiving better treatment than default.

> 
> - It could for instance be OK to say that this document does not 
> define specific techniques to support a Lower Effort PHB, therefore 
> the method provided by this recommendation would result in this being 
> mapped remarked with DSCP CS0 at a Diffserv-Intercon network 
> interconnection. However, if this is the approach taken by the WG, I think it then needs to state the ways in which this can be a problem to LBE traffic. Perhaps (?) it could possibly conclude that this is not worse than being done at present?
> 

The problem here is that RFC 3662 is broken. I've never been very comfortable with the whole LE concept, and I think that the suggestion of using the codepoint standardised for CS1 was broken from the start. I don't think any of the document that talk about LE can be fixed properly unless we fix 3662.

Regards
     Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 May 2016 08:04:10 +0100

> LE can be fixed properly unless we fix 3662.
Personally, I would in future hope we may see some enthusiasm to deploy 
a LE class. This could provide DS support for scavenger service. 
However, that is something which would need to update several RFCs and 
to gain community consensus. I agree  the Diffserv-Intercon ID is likely 
the wrong place to make this happen, but I would like to encourage us to 
see if we can find words that at least acknowledge the present 
situation. Let me see if I can suggest anything different that is useful?

One apprroach could be to state something like:

"This document does not specify an interconnection class for RFC 4594 
Low-priority data. This data may be forwarded by a Lower Effort PHB in 
one domain (like the PHB proposed by Informational [RFC3662]), but  
using the methods specified in this document will be remarked with DSCP 
CS0 at a Diffserv-Intercon network interconnection. This has the effect 
that Low-priority data is treated the same as data sent using the 
default class.(Note: In a network that implements RFC 2474, Low-priority 
traffic marked as CS1 would otherwise receive better treatment than 
traffic using the default class.)"

Gorry

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 18 May 2016 09:56:28 +0200

Hi,

see comments inline.

> collateral damage will then result in sharing the network capacity with

One of the LE original intents was to actually "protect" best-effort
traffic from lower priority traffic. Therefore, this LE handling is then
in contrast to its original goals. Moreover, applications do not get
the expected behavior.

> (?) it could possibly conclude that this is not worse than being done at

My suggestion: I write up a draft for allocation of a DSCP for Lower
Effort PDB traffic in order to get forward with LE deployment
and get away from its DSCP ambiguity with the CS0 recommendation.
The rationale is that the LE PDB is extremely easy to support
since it requires no traffic conditioning and "does no harm" to
other traffic classes. In case a domain doesn't support LE (i.e.,
the LE DSCP then gets mapped to the default PHB = BE), we
could at least keep the DSCP as is without bleaching it.

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 18 May 2016 10:08:42 +0200

Hi,

> that's how "LE" traffic travels today anyway, since LE is not significantly

I don't know what provider networks do today, but LE was deployed
very quickly in several research networks like Internet-2 and GEANT.
It really doesn't require very much except its own queue and a
simple priority scheduler, but no traffic profiles, meters, shapers
and so on. So deployment is easy compared to other PHBs/PDBs.
Even in my DSL router I have support for LE, it is suggested to
being used for background traffic.

> whole LE concept, and I think that the suggestion of using the codepoint standardised

LE has a lot of benefits and several applications that can use it. Just
consider synchronization of online storage and backups to cloud storage
or software updates of operating systems. Major rollouts of the latter
(even for smartphone OSes) usually cause significant load in provider
networks.

> LE can be fixed properly unless we fix 3662.

I fully agree here and as you know I was strongly against using CS1
at that point in time. So I volunteer to write up a draft that updates
RFC 3662 w.r.t. the recommended codepoint, or should I update RFC 3662
itself?

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 May 2016 08:53:11 +1200

Hi Roland,

On 18/05/2016 20:08, Bless, Roland (TM) wrote:

...
> RFC 3662 w.r.t. the recommended codepoint, or should I update RFC 3662

Personally, I think it would be better to write a standards track draft that
completely replaces RFC 3662. We could argue that RFC 3662 should have been
an Experimental RFC in the first place, and that there is indeed operational
experience that justifies Proposed Standard status now, and the assignment
of a specific code point.

I won't volunteer to co-author but I will be glad to carefully review such
a draft.

Regards
    Brian

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 May 2016 00:17:21 +0000

> I won't volunteer to co-author but I will be glad to carefully review such

+1 with WG chair hat on.

Given the evidence that CS1 LE experiments have been run (and moreover have
been successful), the WG could ask the IESG to reclassify RFC 3662 as Experimental.

I concur with Brian that RFC 3662 has a number of problems, among which is
that its CS1 language is sufficiently weak so that the RFC reference for use of
CS1 for Lower Effort traffic turns out to be RFC 4594, not RFC 3662.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, May 18, 2016 4:53 PM
> To: Bless, Roland (TM); [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-diffserv-intercon-05
> 
> Hi Roland,
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 May 2016 00:32:00 +0000

> traffic using the default class.)"

I don't have a problem with that text - it looks like a longer version of
what was originally intended where the goal of the expansion is to make
it much clearer that this is a  descriptive discussion of Lower Effort traffic,
not prescriptive. 

Prescriptive text was not intended, and making it clearer that this text
is only a description of what will happen looks like an improvement to me.

Thanks, --David (as draft co-author).

> From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Wednesday, May 18, 2016 3:04 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> >> I know the inclusion of a new class for LBE was discussed, and has not been
> taken forward, the recommendation  seems broken in
> >> the current text:
> >>
> >>          / RFC 4594
> >>
> >> - My concern is that there may have significant implications if you follow this
> approach to the future deployability of the
> >> Lower Effort PHB, if there is a significant proportion of this low priority traffic,
> or that traffic that relies upon this DSCP
> >> - It could for instance be OK to say that this document does not define specific
> techniques to support a Lower Effort PHB,
> >> Diffserv-Intercon network interconnection. However, if this is the approach
> taken by the WG, I think it then needs to state the
> >> ways in which this can be a problem to LBE traffic. Perhaps (?) it could possibly
> conclude that this is not worse than being
> >> done at present?
> >>

---

From: <[email-masked]>
Date: Thu, 19 May 2016 07:21:47 +0000

Allright, I'll incorporate the text suggested by Gorry. The current text

/ RFC 4594 Low-priority data may be forwarded by a Lower Effort 
PHB in one domain (like the PHB proposed by Informational
 [RFC3662]), but is remarked with DSCP CS0 at a Diffserv-
Intercon network interconnection./

will be removed.

I may need some more time to produce the next version.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Black, David
Gesendet: Donnerstag, 19. Mai 2016 02:32
An: [email-masked]; Brian E Carpenter
Cc: [email-masked]
Betreff: Re: [tsvwg] Comments on draft-ietf-tsvwg-diffserv-intercon-05

> using the methods specified in this document will be remarked with 
> DSCP CS0 at a Diffserv-Intercon network interconnection. This has the 
> effect that Low-priority data is treated the same as data sent using 
> the default class.(Note: In a network that implements RFC 2474, 
> Low-priority traffic marked as CS1 would otherwise receive better 
> treatment than traffic using the default class.)"

I don't have a problem with that text - it looks like a longer version of what was originally intended where the goal of the expansion is to make it much clearer that this is a  descriptive discussion of Lower Effort traffic, not prescriptive. 

Prescriptive text was not intended, and making it clearer that this text is only a description of what will happen looks like an improvement to me.

> >> follow this
> >> to protect other traffic from collateral damage will then result in 
> >> sharing the
> network capacity with the default class.
> > Do you have a better suggestion? As far as I can see, the *least* 
> > damage you can do when re-marking LE traffic is to mark it as 
> > default. In the real world, that's how "LE" traffic travels today 
> > anyway, since LE is not significantly deployed afaik.
> >
> > Certainly, re-marking LE as default is clearly better than leaving 
> > it marked with the code point that is standardised as CS1, if the 
> > LE-supporting network is using that code point as suggested by RFC 
> > 3662. In a network that implements RFC 2474, that would result in 
> > the "LE" traffic receiving better treatment than default.
> >
> >> define specific
> >> therefore the method provided by this recommendation would result 
> >> in this
> being mapped remarked with DSCP CS0 at a
> > The problem here is that RFC 3662 is broken. I've never been very 
> > comfortable
> with the
> > whole LE concept, and I think that the suggestion of using the 
> > codepoint
> standardised
> > for CS1 was broken from the start. I don't think any of the document 
> > that talk
> about
> Personally, I would in future hope we may see some enthusiasm to 
> deploy a LE class. This could provide DS support for scavenger service.
> to gain community consensus. I agree  the Diffserv-Intercon ID is 
> likely the wrong place to make this happen, but I would like to 
> encourage us to see if we can find words that at least acknowledge the 
> present situation. Let me see if I can suggest anything different that is useful?
> 
> using the methods specified in this document will be remarked with 
> DSCP CS0 at a Diffserv-Intercon network interconnection. This has the 
> effect that Low-priority data is treated the same as data sent using 
> the default class.(Note: In a network that implements RFC 2474, 
> Low-priority traffic marked as CS1 would otherwise receive better 
> treatment than traffic using the default class.)"
> 
> 
> Gorry

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 19 May 2016 13:02:47 +0200

Hi Brian,

> of a specific code point.

RFC 3662 was informational since there was a consensus in the DiffServ
WG that all PDBs should be informational RFCs (Documented in
https://tools.ietf.org/html/rfc3086#section-8). Originally, we thought
of the Lower Effort concept as being a PHB and that's why we initially
proposed it that way in
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00
However, the DiffServ WG chairs at that time thought it would be
better to specify it as PDB and reuse some existing codepoints instead
of using a dedicated one.

The intercon draft obviously (but incorrectly) also speaks of a PHB:

 "Low-priority data may be forwarded by a Lower Effort PHB one domain
(like the PHB proposed by Informational [RFC3662]),"

Therefore, I probably want to write it as PHB again, since the
corresponding PDB is trivial: it doesn't require any traffic
conditioning mechanisms.

> I won't volunteer to co-author but I will be glad to carefully review such

Great.

Best regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 May 2016 12:52:02 +1200

> of using a dedicated one.

I don't remember the second point, but if that's what the diffserv
chairs said, we were wrong :-(. Technically, the WG was closed
before the RFC was approved. But Kathy was a co-author and I reviewed
the draft, so no excuses are available.

Regards
   Brian