headers
John Wroclawski | 20 Jun 2012 10:55
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Hello,

On Jun 20, 2012, at 12:50 AM, Ruediger Geib <Ruediger.Geib <at> telekom.de> wrote:
>  Brian,
>
>  [RG] below indicates my replies to your statements (marked as [BC]).
>
>  Regards, Rüdiger
>
>  [BC] IMHO, this is confusing and misses part of the diffserv model.
>  Rather than explaining what's wrong, here is a suggested rewrite:
>
>  [RG-start] What you say is the PHB needs to be stable end-to-end
>  and the DSCP can (and looking at the deployments I am aware of
>  often will) vary?

However the original diffserv model specifically 
contemplated that the PHB might *not* be stable 
from end to end.

Since the per hop behavior applied to a packet is 
only one aspect of the overall QOS seen by that 
packet within an administrative domain, there are 
two reasons this might be so.

1) Different administrative domains along an end 
to end path are using different technical means - 
different combinations of PHB, border traffic 
shaping, admission control, overcapacity, etc - 
to implement the same overall QOS for a service
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 20 Jun 2012 17:14
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

On 2012-06-20 09:55, John Wroclawski wrote:
> Hello,
> 
> On Jun 20, 2012, at 12:50 AM, Ruediger Geib <Ruediger.Geib <at> telekom.de>
> wrote:
>>  Brian,
>>
>>  [RG] below indicates my replies to your statements (marked as [BC]).
>>
>>  Regards, Rüdiger
>>
>>  [BC] IMHO, this is confusing and misses part of the diffserv model.
>>  Rather than explaining what's wrong, here is a suggested rewrite:
>>
>>  [RG-start] What you say is the PHB needs to be stable end-to-end
>>  and the DSCP can (and looking at the deployments I am aware of
>>  often will) vary?
> 
> However the original diffserv model specifically contemplated that the
> PHB might *not* be stable from end to end.

Yes, indeed - you can only assume stability if there are e2e agreements
in place; the only safe assumption is that it might change.

> Since the per hop behavior applied to a packet is only one aspect of the
> overall QOS seen by that packet within an administrative domain, there
> are two reasons this might be so.
> 
> 1) Different administrative domains along an end to end path are using
> different technical means - different combinations of PHB, border
(Continue reading)

Permalink | Reply |
headers
Ruediger.Geib | 21 Jun 2012 09:21
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

>>>  [RG-start] What you say is the PHB needs to be stable end-to-end
>>>  and the DSCP can (and looking at the deployments I am aware of
>>>  often will) vary?
>>
BC  If you want consistent behaviour from end to end, that is correct,
>>  and that was the intention from the beginning.
>
JW  In fact I'd say rather that the intention was to support the notion that
> different administrative domains might explicitly choose to implement
> the same QOS for a flow or class of packets using different technical
> means, as convenient and appropriate for the domain, and that this
> should be supported in the architecture.

[BC]
Yes, you are correct, but a set of operators who choose to use the same
set of PHBs can achieve more consistent behaviour by doing so. However,
if a stream of packets arrives via an operator who does not make the same
choice, it needs to be reclassified and re-marked (in the simplest case,
marked as Best Effort); there's no way out of that.

Therefore, even if a BCP is published that defines a recommended set
of PHBs, you still need to classify traffic from any source that is
not definitely known to implement that BCP.

[RG]
Thank's Brian, that's exactly what the company I work for can't deal
with. Quality of Service as described above is a "maybe". It
can't be defined in commercial terms, monitored or operated or be
explained to a customer.
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 21 Jun 2012 14:32
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

I need to highlight one remark by Rüdiger:

On 2012-06-21 08:21, Ruediger.Geib <at> telekom.de wrote:
...
> Quality of Service as described above is a "maybe". It
> can't be defined in commercial terms, monitored or operated or be
> explained to a customer.

That is Internet 101. I've been dealing with operators such as
your employer since the time when they were still called PTTs,
and I know that this is as hard for them to accept now as it was
in 1990. However, there will *always* be best effort traffic in
the Internet, and I suspect it will always be the majority of
traffic. As I have been known to say, you can't beat queueing
theory. At best, diffserv can partially compensate for this, but
that's all.

I understand that this may be hard to explain to business
managers, but it does set limits on what we can achieve.

    Brian
Permalink | Reply |
headers
Ruediger.Geib | 22 Jun 2012 13:29
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Brian,

the core network of the company I work for is as
connectionless as can be, i.e. we apply metric
optimisation based Traffic Engineering.
This is made QoS aware. We've adapted our core network
architecture, introduced Traffic Engineering and deployed
QoS from 2000 on. The resulting service is meeting commercial
service requirements (I recall my boss having a smile in
his face when he compared figures of measured IP core
delay variation with the 125 us of ISDN).

The IP/MPLS core network exposes deterministic behaviour
under foreseeable operational conditions.

This I expect to be true for all carriers applying
Traffic Engineering. But also data center providers
nowadays engineer their infrastructure on other factors
than just cost.

Part of all the engineering is based on an assumption,
that the majority of traffic will be Best Effort.

I hope, you and other senior IETF members keep in mind,
that while the age of PTTs is over, also the "Internet
of 1990" is no longer existing.

Regards,

Rüdiger
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 22 Jun 2012 13:50
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Rüdiger,

I don't think we disagree in any fundamental way. However, when
you say "we've deployed QoS from 2000 on", can you state which
technology you mean?

Regards
   Brian Carpenter

On 2012-06-22 12:29, Ruediger.Geib <at> telekom.de wrote:
> Brian,
> 
> the core network of the company I work for is as
> connectionless as can be, i.e. we apply metric
> optimisation based Traffic Engineering.
> This is made QoS aware. We've adapted our core network
> architecture, introduced Traffic Engineering and deployed
> QoS from 2000 on. The resulting service is meeting commercial
> service requirements (I recall my boss having a smile in
> his face when he compared figures of measured IP core
> delay variation with the 125 us of ISDN).
> 
> The IP/MPLS core network exposes deterministic behaviour
> under foreseeable operational conditions.
> 
> This I expect to be true for all carriers applying
> Traffic Engineering. But also data center providers
> nowadays engineer their infrastructure on other factors
> than just cost.
>
(Continue reading)

Permalink | Reply |
headers
Ruediger.Geib | 22 Jun 2012 16:11
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Brian,

would the he reply

DiffServ, deployed in the complete core network (IP and MPLS)

be sufficient? Up to now, we didn't deploy or operate any RSVP
based solutions.

Regards,

Rüdiger

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter <at> gmail.com]
Sent: Friday, June 22, 2012 1:50 PM
To: Geib, Rüdiger
Cc: tsvwg <at> ietf.org
Subject: Re: [tsvwg] I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

Rüdiger,

I don't think we disagree in any fundamental way. However, when
you say "we've deployed QoS from 2000 on", can you state which
technology you mean?

Regards
   Brian Carpenter

On 2012-06-22 12:29, Ruediger.Geib <at> telekom.de wrote:
(Continue reading)

Permalink | Reply |
headers
Ruediger.Geib | 21 Jun 2012 09:09
Picon

Re: I-D Action: draft-polk-diffserv-stds-problem-statement-00.txt

John,

you've emphasised

  1) Different administrative domains along an end
  to end path are using different technical means -
  different combinations of PHB, border traffic
  shaping, admission control, overcapacity, etc -
  to implement the same overall QOS for a service
  class, or

  2) Different administrative domains along an end
  to end path are providing different QOS to the
  data flow due to different administrative
  agreements, etc.

I'd like to understand which approach you favour:

- RFC4594 is informational and should be left like
  that to continue giving freedom while deploying
  DiffServ.

- Standardise a limited set of PHBs and assigned
  codepoints. This allows for some E2E QoS
  deployments and leaves room for other, more
  flexible deployments.

- Standardise all QoS class/codepoint assignments
  of RFC4594 and add some new ones. This limits
  space for deployment of flexible schemes.
(Continue reading)

Permalink | Reply |

Gmane