Subject: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 May 2018 07:56:16 +0000

Godred and all,
I have looked up the draft<https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04>, and I have doubts regarding validity of its motivation.
The draft says - correctly -that 22 out of 32 values in Pool 1 of the DSCP code points have been already assigned, therefore it considers this pool as nearly exhausted.

What the draft does not say that, out of these 22 assignments, 2o have been done in 1998 and one - in 1999. Only one assignment has been requested in the past 19 years, and no assignments have been requested after 2010.

At this rate my estimate is that Pool 1 would suffice for the next 50+ years without its exhaustion becoming an issue. So why should the IETF do anything now?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 8 May 2018 11:13:58 +0200 (CEST)

> At this rate my estimate is that Pool 1 would suffice for the next 50+ years without its exhaustion becoming an issue. So why should the IETF do anything now?

The primary reason for this is not because pool 1 is becoming exhausted, 
but the fact that we want to use 000001 for LE (for practical/legacy 
reasons, not because pool 1 is becoming exhausted), so the suggestion is 
therefore to make Pool 3 have a different allocation policy so we can put 
in a standards track PHB LE RFC for 000001.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 8 May 2018 11:25:36 +0200

Hi Sasha,

Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein:
> I have looked up the draft
> <https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04>,
> and I have doubts regarding validity of its motivation.
> 
> The draft says – correctly -that 22 out of 32 values in Pool 1 of the
> DSCP code points have been already assigned, therefore it considers this
> pool as nearly exhausted.
> 
> What the draft does not say that, out of these 22 assignments, 2o have
> been done in 1998 and one – in 1999. Only one assignment has been
> requested in the past 19 years, and no assignments have been requested
> after 2010.

> At this rate my estimate is that Pool 1 would suffice for the next 50+
> years without its exhaustion becoming an issue. So why should the IETF
> do anything */now/*?

This is motivated in section 1:

   The rationale for this update is a need
   to assign codepoints for particular PHBs that are unable to use any
   of the unassigned values in Pool 1.

This problem is caused by implementations that
do IP precedence bleaching (i.e., zeroing the
top three bits of the DSCP) thereby rewriting
(or unintentionally mapping) DSCP values to other
DSCP values. This is a problem for the mentioned
LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb
It is possible that some other standardized DSCPs get mapped to
the LE PHB DSCP if the LE DSCP were taken from the DSCP standards
action pool 1 (xxxxx0).

There are measurements and more background material for this:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00
https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf

Regards,
 Roland

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 May 2018 14:07:50 +0000

Ronald,
Lots of thanks for a prompt response.

I have to admit that your explanation looks problematic to me.
It provides a workaround for the IP precedence bleaching for LE traffic that you want to introduce - but what about all other PHBs?
Would they not require some intelligent rewrite of the DSCP when traffic enters the bleaching domain?
And if so, why should not the same approach be used for LE in this domain?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Bless, Roland (TM) [mailto:[email-masked]] 
Sent: Tuesday, May 8, 2018 12:26 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

Hi Sasha,

Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein:
> The draft says - correctly -that 22 out of 32 values in Pool 1 of the 
> DSCP code points have been already assigned, therefore it considers 
> this pool as nearly exhausted.
> 
> been done in 1998 and one - in 1999. Only one assignment has been 

This problem is caused by implementations that do IP precedence bleaching (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or unintentionally mapping) DSCP values to other DSCP values. This is a problem for the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb
It is possible that some other standardized DSCPs get mapped to the LE PHB DSCP if the LE DSCP were taken from the DSCP standards action pool 1 (xxxxx0).

Regards,
 Roland

---

From: "Black, David" <[email-masked]>
Date: Tue, 8 May 2018 14:46:22 +0000

Writing as an individual, not WG chair ...

> It provides a workaround for the IP precedence bleaching for LE traffic that
> you want to introduce - but what about all other PHBs?

The concern is not about what happens in Diffserv domains/regions that are updated to implement support for the new LE PHB, but what happens when that LE PHB traffic transits through routers elsewhere that bleach IP Precedence.

Right now IP Precedence bleaching tends to result in best effort service, which is ok, albeit not ideal.   If IP Precedence bleaching could result in a DSCP for the LE PHB, the result downstream of the bleaching could be worse than best effort service for a DSCP that was intended to obtain better than best effort service - that is the priority inversion that we're trying to avoid.

> enters the bleaching domain?

Unfortunately, that's wishful thinking, IMHO.  IP Precedence bleaching already violates a bunch of RFCs, dating back to RFC 2474.    We can write what we like in a new RFC, but that "running code" in deployed routers isn't going to magically stop bleaching IP Precedence just because we publish a new RFC.

Thanks, --David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Alexander
> Vainshtein
> Sent: Tuesday, May 8, 2018 10:08 AM
> To: Bless, Roland (TM)
> Cc: [email-masked]; [email-masked]
> It provides a workaround for the IP precedence bleaching for LE traffic that
> you want to introduce - but what about all other PHBs?
> This problem is caused by implementations that do IP precedence bleaching
> (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or
> unintentionally mapping) DSCP values to other DSCP values. This is a problem
> for the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le-
> phb
> It is possible that some other standardized DSCPs get mapped to the LE PHB
> DSCP if the LE DSCP were taken from the DSCP standards action pool 1
> (xxxxx0).
> 
> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-
> 31measurements-concerning-the-dscp-for-a-le-phb-00

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 May 2018 14:55:32 +0000

David,
Lots of thanks for a very detailed explanation.

Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16 values) in order to make just one value standard still looks an exaggeration to me. 
What are we going to do with the remaining 15 values? 

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Tuesday, May 8, 2018 5:46 PM
To: Alexander Vainshtein <[email-masked]>; Bless, Roland (TM) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

> It provides a workaround for the IP precedence bleaching for LE 
> traffic that you want to introduce - but what about all other PHBs?

Thanks, --David

> Subject: Re: [tsvwg] Doubts regarding motivation of 
> draft-ietf-tsvwg-iana-
> dscp-registry-04
> 
> Ronald,
> It provides a workaround for the IP precedence bleaching for LE 
> traffic that you want to introduce - but what about all other PHBs?
> Subject: Re: [tsvwg] Doubts regarding motivation of 
> draft-ietf-tsvwg-iana-
> dscp-registry-04
> 
> Hi Sasha,
> 
> > <https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04>
> > , and I have doubts regarding validity of its motivation.
> >
> > The draft says - correctly -that 22 out of 32 values in Pool 1 of 
> > the DSCP code points have been already assigned, therefore it 
> > considers this pool as nearly exhausted.
> >
> > What the draft does not say that, out of these 22 assignments, 2o 
> > have been done in 1998 and one - in 1999. Only one assignment has 
> > been requested in the past 19 years, and no assignments have been 
> > requested after 2010.
> 
> > At this rate my estimate is that Pool 1 would suffice for the next 
> > 50+ years without its exhaustion becoming an issue. So why should 
> > the IETF do anything */now/*?
> 
> This problem is caused by implementations that do IP precedence 
> bleaching (i.e., zeroing the top three bits of the DSCP) thereby 
> rewriting (or unintentionally mapping) DSCP values to other DSCP 
> values. This is a problem for the mentioned LE PHB I-D 
> https://tools.ietf.org/html/draft-ietf-tsvwg-le-
> phb
> It is possible that some other standardized DSCPs get mapped to the LE 
> PHB DSCP if the LE DSCP were taken from the DSCP standards action pool 
> 1 (xxxxx0).
> 
> This e-mail message is intended for the recipient only and contains 
> information which is CONFIDENTIAL and which may be proprietary to ECI 
> Telecom. If you have received this transmission in error, please 
> inform us by e-mail, phone or fax, and then delete the original and 
> all copies thereof.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 8 May 2018 19:48:56 +0100

Hi,

Maybe I can provide a little more context about other unallocated values in the registry. Each request for a new DSCP needs to be considered carefully and separately looking at the implications on both the deployed use of Codepoints and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1 could well remain useful for any new PHBs- if any new ones are approved by TSVWG  that can be bleached to default (BE) - the case for most currently defined PHBs. 

I expect the  new pool will be only used by IANA requests from TSVWG when there is a case for not using any of the remaining pool 1 values. That case has been made for the LE PHB.  There could potentially be other allocations in the future, but that is none are currently considered.

Gorry

Sent from my iPad

> On 8 May 2018, at 15:55, Alexander Vainshtein <[email-masked]> wrote:
> 
> David,

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 8 May 2018 19:42:21 +0000

Gorry,
Providing additional context including explicit description of bleaching of the IP Precedence bits would surely help.

Thumb typed by Sasha Vainshtein

From: Gorry Fairhurst
Sent: Tuesday, May 8, 21:49
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
To: Alexander Vainshtein
Cc: Black, David, [email-masked], Bless, Roland (TM)

Hi, Maybe I can provide a little more context about other unallocated values in the registry. Each request for a new DSCP needs to be considered carefully and separately looking at the implications on both the deployed use of Codepoints and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1 could well remain useful for any new PHBs- if any new ones are approved by TSVWG that can be bleached to default (BE) - the case for most currently defined PHBs. I expect the new pool will be only used by IANA requests from TSVWG when there is a case for not using any of the remaining pool 1 values. That case has been made for the LE PHB. There could potentially be other allocations in the future, but that is none are currently considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander Vainshtein wrote: > > David, > Lots of thanks for a very detailed explanation. > > Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16 values) in order to make just one value standard still looks an exaggeration to me. > What are we going to do with the remaining 15 values? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email-masked] > > > -----Original Message----- > From: Black, David [mailto:[email-masked]] > Sent: Tuesday, May 8, 2018 5:46 PM > To: Alexander Vainshtein ; Bless, Roland (TM) > Cc: [email-masked]; [email-masked] > Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 > > Writing as an individual, not WG chair ... > >> It provides a workaround for the IP precedence bleaching for LE >> traffic that you want to introduce - but what about all other PHBs? > > The concern is not about what happens in Diffserv domains/regions that are updated to implement support for the new LE PHB, but what happens when that LE PHB traffic transits through routers elsewhere that bleach IP Precedence. > > Right now IP Precedence bleaching tends to result in best effort service, which is ok, albeit not ideal. If IP Precedence bleaching could result in a DSCP for the LE PHB, the result downstream of the bleaching could be worse than best effort service for a DSCP that was intended to obtain better than best effort service - that is the priority inversion that we're trying to avoid. > >> Would they not require some intelligent rewrite of the DSCP when >> traffic enters the bleaching domain? > > Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching already violates a bunch of RFCs, dating back to RFC 2474. We can write what we like in a new RFC, but that "running code" in deployed routers isn't going to magically stop bleaching IP Precedence just because we publish a new RFC. > > Thanks, --David > >> -----Original Message----- >> From: tsvwg [mailto:[email-masked]] On Behalf Of Alexander >> Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> To: Bless, Roland (TM) >> Cc: [email-masked]; [email-masked] >> Subject: Re: [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> >> Ronald, >> Lots of thanks for a prompt response. >> >> I have to admit that your explanation looks problematic to me. >> It provides a workaround for the IP precedence bleaching for LE >> traffic that you want to introduce - but what about all other PHBs? >> Would they not require some intelligent rewrite of the DSCP when >> traffic enters the bleaching domain? >> And if so, why should not the same approach be used for LE in this domain? >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: [email-masked] >> >> >> -----Original Message----- >> From: Bless, Roland (TM) [mailto:[email-masked]] >> Sent: Tuesday, May 8, 2018 12:26 PM >> To: Alexander Vainshtein ; >> [email-masked] >> Cc: [email-masked] >> Subject: Re: [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> >> Hi Sasha, >> >>> Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I have looked up the draft >>> >>> , and I have doubts regarding validity of its motivation. >>> >>> The draft says - correctly -that 22 out of 32 values in Pool 1 of >>> the DSCP code points have been already assigned, therefore it >>> considers this pool as nearly exhausted. >>> >>> What the draft does not say that, out of these 22 assignments, 2o >>> have been done in 1998 and one - in 1999. Only one assignment has >>> been requested in the past 19 years, and no assignments have been >>> requested after 2010. >> >>> At this rate my estimate is that Pool 1 would suffice for the next >>> 50+ years without its exhaustion becoming an issue. So why should >>> the IETF do anything */now/*? >> >> This is motivated in section 1: >> >> The rationale for this update is a need >> to assign codepoints for particular PHBs that are unable to use any >> of the unassigned values in Pool 1. >> >> This problem is caused by implementations that do IP precedence >> bleaching (i.e., zeroing the top three bits of the DSCP) thereby >> rewriting (or unintentionally mapping) DSCP values to other DSCP >> values. This is a problem for the mentioned LE PHB I-D >> https://tools.ietf.org/html/draft-ietf-tsvwg-le- >> phb >> It is possible that some other standardized DSCPs get mapped to the LE >> PHB DSCP if the LE DSCP were taken from the DSCP standards action pool >> 1 (xxxxx0). >> >> There are measurements and more background material for this: >> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess >> b- >> 31measurements-concerning-the-dscp-for-a-le-phb-00 >> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >> >> Regards, >> Roland >> >> __________________________________________________________ >> _________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> __________________________________________________________ >> _________________ > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 May 2018 08:46:17 +1200

> What are we going to do with the remaining 15 values? 

To be honest, probably nothing. Having as many as 6 bits to select a per-hop
behaviour has always seemed like a lot (and led to rather complex solutions
such as 4 distinct AF classes each with 3 drop precedences).

However, if somebody ever came along with a need for a very large number
of local-use PHBs, there's nothing to stop them using Pool 3, since
all DSCP values are RECOMMENDED anyway, except for CS0-7. 
(Paragraph 3 at https://tools.ietf.org/html/rfc2474#page-8 )

This is the irony of having misused CS1 for LE - it's one of the few code
points that is truly mandated by RFC2474.

    Brian

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 May 2018 08:19:25 +0000

Gorry and all,
I have looked up the -05 revision of the draft, and it provides a reasonable explanation of motivation.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Tuesday, May 8, 2018 10:42 PM
To: Gorry Fairhurst <[email-masked]>
Cc: Black, David <[email-masked]>; [email-masked]; Bless, Roland (TM) <[email-masked]>
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

Gorry,

From: Gorry Fairhurst
Sent: Tuesday, May 8, 21:49
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
To: Alexander Vainshtein
Cc: Black, David, [email-masked]<mailto:[email-masked]>, Bless, Roland (TM)

Hi, Maybe I can provide a little more context about other unallocated values in the registry. Each request for a new DSCP needs to be considered carefully and separately looking at the implications on both the deployed use of Codepoints and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1 could well remain useful for any new PHBs- if any new ones are approved by TSVWG that can be bleached to default (BE) - the case for most currently defined PHBs. I expect the new pool will be only used by IANA requests from TSVWG when there is a case for not using any of the remaining pool 1 values. That case has been made for the LE PHB. There could potentially be other allocations in the future, but that is none are currently considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander Vainshtein wrote: > > David, > Lots of thanks for a very detailed explanation. > > Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16 values) in order to make just one value standard still looks an exaggeration to me. > What are we going to do with the remaining 15 values? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email-masked]<mailto:[email-masked]> > > > -----Original Message----- > From: Black, David [mailto:[email-masked]] > Sent: Tuesday, May 8, 2018 5:46 PM > To: Alexander Vainshtein ; Bless, Roland (TM) > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> > Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 > > Writing as an individual, not WG chair ... > >> It provides a workaround for the IP precedence bleaching for LE >> traffic that you want to introduce - but what about all other PHBs? > > The concern is not about what happens in Diffserv domains/regions that are updated to implement support for the new LE PHB, but what happens when that LE PHB traffic transits through routers elsewhere that bleach IP Precedence. > > Right now IP Precedence bleaching tends to result in best effort service, which is ok, albeit not ideal. If IP Precedence bleaching could result in a DSCP for the LE PHB, the result downstream of the bleaching could be worse than best effort service for a DSCP that was intended to obtain better than best effort service - that is the priority inversion that we're trying to avoid. > >> Would they not require some intelligent rewrite of the DSCP when >> traffic enters the bleaching domain? > > Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching already violates a bunch of RFCs, dating back to RFC 2474. We can write what we like in a new RFC, but that "running code" in deployed routers isn't going to magically stop bleaching IP Precedence just because we publish a new RFC. > > Thanks, --David > >> -----Original Message----- >> From: tsvwg [mailto:[email-masked]] On Behalf Of Alexander >> Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> To: Bless, Roland (TM) >> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> >> Subject: Re: [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> >> Ronald, >> Lots of thanks for a prompt response. >> >> I have to admit that your explanation looks problematic to me. >> It provides a workaround for the IP precedence bleaching for LE >> traffic that you want to introduce - but what about all other PHBs? >> Would they not require some intelligent rewrite of the DSCP when >> traffic enters the bleaching domain? >> And if so, why should not the same approach be used for LE in this domain? >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: [email-masked]<mailto:[email-masked]> >> >> >> -----Original Message----- >> From: Bless, Roland (TM) [mailto:[email-masked]] >> Sent: Tuesday, May 8, 2018 12:26 PM >> To: Alexander Vainshtein ; >> [email-masked]<mailto:[email-masked]> >> Cc: [email-masked]<mailto:[email-masked]> >> Subject: Re: [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> >> Hi Sasha, >> >>> Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I have looked up the draft >>> >>> , and I have doubts regarding validity of its motivation. >>> >>> The draft says - correctly -that 22 out of 32 values in Pool 1 of >>> the DSCP code points have been already assigned, therefore it >>> considers this pool as nearly exhausted. >>> >>> What the draft does not say that, out of these 22 assignments, 2o >>> have been done in 1998 and one - in 1999. Only one assignment has >>> been requested in the past 19 years, and no assignments have been >>> requested after 2010. >> >>> At this rate my estimate is that Pool 1 would suffice for the next >>> 50+ years without its exhaustion becoming an issue. So why should >>> the IETF do anything */now/*? >> >> This is motivated in section 1: >> >> The rationale for this update is a need >> to assign codepoints for particular PHBs that are unable to use any >> of the unassigned values in Pool 1. >> >> This problem is caused by implementations that do IP precedence >> bleaching (i.e., zeroing the top three bits of the DSCP) thereby >> rewriting (or unintentionally mapping) DSCP values to other DSCP >> values. This is a problem for the mentioned LE PHB I-D >> https://tools.ietf.org/html/draft-ietf-tsvwg-le- >> phb >> It is possible that some other standardized DSCPs get mapped to the LE >> PHB DSCP if the LE DSCP were taken from the DSCP standards action pool >> 1 (xxxxx0). >> >> There are measurements and more background material for this: >> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess >> b- >> 31measurements-concerning-the-dscp-for-a-le-phb-00 >> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >> >> Regards, >> Roland >> >> __________________________________________________________ >> _________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> __________________________________________________________ >> _________________ > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________