Subject: [tsvwg] New draft on Lower Effort PHB draft-bless-tsvwg-le-phb-00.txt

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 11 Jul 2016 16:30:44 +0200

Hi,

Following from the draft-ietf-tsvwg-diffserv-intercon draft discussion,
I tried to have a first submission of the LE PHB draft before the
deadline. So the main intention is to allocate an unambiguous
DSCP for it, so that global deployment can progress. This PHB
is particularly easy to deploy since it does no harm to other
traffic...
The I-D didn't get the time I wanted to spend for it, but it's a
start. Still missing are more detailed discussion on remarking
as well as history / acknowledgements to earlier documents...

If there is time left on the agenda I can briefly (5-10min)
present it in Berlin.

Regards,
 Roland

-------- Weitergeleitete Nachricht --------
Betreff: New Version Notification for draft-bless-tsvwg-le-phb-00.txt
Datum: Fri, 08 Jul 2016 16:15:10 -0700
Von: [email-masked]
An: Roland Bless <[email-masked]>

A new version of I-D, draft-bless-tsvwg-le-phb-00.txt
has been successfully submitted by Roland Bless and posted to the
IETF repository.

Name:		draft-bless-tsvwg-le-phb
Revision:	00
Title:		A Lower Effort Per-Hop Behavior (LE PHB)
Document date:	2016-07-09
Group:		Individual Submission
Pages:		7
URL:
https://www.ietf.org/internet-drafts/draft-bless-tsvwg-le-phb-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bless-tsvwg-le-phb/
Htmlized:       https://tools.ietf.org/html/draft-bless-tsvwg-le-phb-00

Abstract:
   This document specifies properties and characteristics of a Lower
   Effort (LE) per-hop behavior (PHB).  The primary objective of this LE
   PHB is to protect best-effort (BE) traffic (packets forwarded with
   the default PHB) from LE traffic in congestion situations, i.e., when
   resources become scarce, best-effort traffic has precedence over LE
   traffic and may preempt it.  There are numerous uses for this PHB,
   e.g., for background traffic of low precedence, such as bulk data
   transfers with low priority in time, non time-critical backups,
   larger software updates, web search engines while gathering
   information from web servers and so on.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jul 2016 12:04:26 +1200

Now I've had time to read the draft:

> The recommended codepoint for the LE PHB is 0x000010.

Yes please, ASAP. All we need are the Updates: fixes to the various affected RFCs.

  Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 28 Jul 2016 04:00:56 +0000

An rfcdiff against RFC 3662 shows the removal of a lot of text. Is your perception that the other text was unnecessary, or did you have a different view?

I'd suggest that this obsolete RFC 3662; it does not say that it either obsoletes or updates it, and I'd like it to. Ideally, I think it's RFC 3662 with a different code point (which is not quite true).

> 1.1.  Applicability
> 
>    A Lower Effort PHB is for sending extremely non-critical traffic
>    across a Differentiated Services (DS) domain or DS region.  There
>    should be an expectation that packets of the LE PHB may be delayed or
>    dropped when any other traffic is present.  Use of the LE PHB might
>    assist a network operator in moving certain kinds of traffic or users
>    to off-peak times.

I'd be interested in an operational viewpoint here, if anyone has one to offer. My perception is that operators routinely allow links to fill to about 90% utilization and begin to worry when it exceeds that, as they expect trouble tickets and support calls. Internet2 experimented with an LE code point (which is where the use of CS1 came from), but I'm not aware of a lot of networks that have found it useful.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jul 2016 17:39:57 +1200

> An rfcdiff against RFC 3662 shows the removal of a lot of text. Is your perception that the other text was unnecessary, or did you have a different view?

I'm not Roland, but I always found that 3662 was too wordy.

> I'd suggest that this obsolete RFC 3662; it does not say that it either obsoletes or updates it, and I'd like it to. Ideally, I think it's RFC 3662 with a different code point (which is not quite t…

No, because 3662 didn't actually meet our own rules. We should do it
properly this time (i.e. follow https://tools.ietf.org/html/rfc2474#section-5).

> I'd be interested in an operational viewpoint here, if anyone has one to offer. My perception is that operators routinely allow links to fill to about 90% utilization and begin to worry when it exc…

That's my perception too, but RTCWEB is citing it.

    Brian

---

From: <[email-masked]>
Date: Thu, 28 Jul 2016 06:18:47 +0000

Hi folks,

Deutsche Telekom does not support a Lower Effort PHB (at least for the parts of the IP network I'm aware of).

Regards, Ruediger

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Jul 2016 08:52:15 +0200

Hi Fred,

> An rfcdiff against RFC 3662 shows the removal of a lot of text. Is your perception that the other text was unnecessary, or did you have a different view?

Yes, I tried to reduce the text to more essential parts.

> I'd suggest that this obsolete RFC 3662; it does not say that it either obsoletes or updates it, and I'd like it to. Ideally, I think it's RFC 3662 with a different code point (which is not quite t…

That's a good question. RFC 3662 was formulated as Per-Domain Behavior
while the draft specified it as PHB. I think updating RFC 3662 would be
sufficient. I'll resubmit a new version as draft-tsvwg-... if I
understood correctly.

> I'd be interested in an operational viewpoint here, if anyone has one to offer. My perception is that operators routinely allow links to fill to about 90% utilization and begin to worry when it exc…

That would be interesting, however, one could fill up
the whole capacity with LE, but then one also needs to
monitor the link load w.r.t. different traffic classes,
e.g., subtract the LE traffic aggregate from the whole
capacity.

Regards,
 Roland

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Jul 2016 07:56:17 +0000

> I'd be interested in an operational viewpoint here, if anyone has one to offer. My perception is that operators routinely allow links to fill to about 90% utilization and begin to worry when it exc…

An LBE service ran on GEANT and many European NRENs a few years ago, having been introduced I think around the time of 6NET, using the same code point as Scavenger for interoperability (DSCP 8), but I understand that it had minimal use and was retired a while ago.

Tim

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Jul 2016 23:59:53 +0200

Hi,

On 28.07.2016 at 09:56 Tim Chown wrote:
> An LBE service ran on GEANT and many European NRENs a few years ago,
> having been introduced I think around the time of 6NET, using the
> same code point as Scavenger for interoperability (DSCP 8), but I
> understand that it had minimal use and was retired a while ago.

That's probably correct. The questions is, however, who determined
to run which traffic as lower effort. If applications don't mark
mark their traffic as LE, then one will not see much use of it.
A unique DSCP for LE will help here.

Moreover, I heard several times at IETF meetings that especially
rollouts of major Operating System Updates can cause
serious congestion. If such updates get marked as LE traffic
then the performance of other best-effort traffic will not be
adversely affected. So I think there are several interesting use
cases for LE.

Regards,
 Roland