Subject: Re: [Diffserv-interest] Re: [Diffserv] Hard questions (was:Diffserv PIB approved asInformational RFC)

From: Marcus Brunner <[email-masked]>
Date: Mon, 01 Jul 2002 18:11:23 +0200

I don't feel this is discouraging. It means that IETF is in general doing a 
good job, because it tends to do very easy solutions.
DiffServ is a good solution for a set of problem, but definitly not for all 
QoS related solutions.

To provide hard guarntees is very diffucult in each network architecture. 
Additionally, I personally don't see the problem in the network, but on 
control and management side (or plane using ATM wording).

--On Freitag, 28. Juni 2002 15:42 -0400 Dan Grossman <[email-masked]> 
wrote:

>>
>
> All this is very discouraging, perhaps indicative of a massive failure of
> the Diffserv standardization exercise.  It also raises questions as to
> whether the historical accomodation between the IETF standarization
> process and the business needs of its participants' employers hasn't in
> fact broken down.
>
>> I completely understand that. I even think since the definition of crisp
>> PDB is very complicated, it adds value to solution, which people don't
>> just want to give away for standardization.
>>
>> E.g., we the did the following PDB:
>> - p2p
>
> Can you explain this one?
>

Sorry, point to point.

>>
>> - guaranteed throughput no loss for packets within CIR profile
>> - maximum delay bound
>>
>> We defined configuration rules for our DiffServ implementation. And we
>> are sure this PDB is not implementable with some of the other DiffServ
>> implementations (even if they conform to the standard).
>
> Is the problem that PHBs are underspecified?   Or is the issue in
> classifiers, conditioners, queuing systems and/or schedulers?

I think it is the problem of choosing classifier/ condtioner etc. 
implementations and their calibration/configuration. We honestly don't even 
use PHBs in their general specifications, however we also did not look in 
the new EF spec too thouroughly.

>>
>>
>> > From the process we actually first looked into our implementation and
>> > then
>> tried to figure out how the PDB looks like.
>
> Can you explain a bit more, and, in particular, were you looking at
> quantifiable parameters only, or were there also temporal or other
> behaviors that were affected?

quantifiable parameters only. (The project was actually to figure out 
hardware settings of some of the parameters such that we can provide a set 
of PDB.)

>>
>>
>> On the other hand, for the community and for helping the deployment, a
>> small set of PDBs (even if they are very loose without stringent
>> guarantees) would help. whether we are able to agree on them is a
>> different question, because some of the people are not able to implement
>> them with they DiffServ nodes.
>
> If this is true, then we have created a bunch of standards that don't
> advance interoperability, and thus have failed.  I knew that there were
> problems, but didn't realize that it was this bad.   Is there anything
> that can be learned from this?

Depends a little on what level you want to interooperate (router to router, 
or network to network) he PDB I regard more a network to network issues, 
and there the management and control plane are the more unsolved problem.

But there is hope. We are in contact with some customers which want to 
deploy first services, but this is not only technical, but also 
organisational and adminstative complex in large organisations.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

_______________________________________________
Diffserv-interest mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv-interest

---

From: Dan Grossman <[email-masked]>
Date: Tue, 02 Jul 2002 13:36:46 -0400

> good job, because it tends to do very easy solutions.

I'm don't understand this.   Are you saying that IETF is doing a good job
because its solutions are simple (regardless of how much complexity is needed
to solve the problem) or because it does the easy bits and ignores the complex
ones?

> To provide hard guarntees is very diffucult in each network architecture.

It was relatively easy in ATM , but I won't go there...

> control and management side (or plane using ATM wording).

So you're saying that the next steps toward QoS should be in the context of
NSIS, control/management architectures, etc.?

> > Can you explain this one?

Point to point usually describes topology, not edge-to-edge transfer
characteristics.  What is it about point-to-point that requires a unique set of
transfer characteristics, and what are they?

> the new EF spec too thouroughly.

Was this a matter of some work that Diffserv didn't do, or was it that you
disagreed with the PHBs that were specified?

> hardware settings of some of the parameters such that we can provide a set

So in our taxonomy, many of your issues were really edge-to-edge service issues
rather than PDB issues?  That is, we say that a PDB defines parameters, but
does not specify their values.  In a service, the values are filled in.   Do
you consider the former to be a significant issue, or are the problems only in
the latter?

> and there the management and control plane are the more unsolved problem.

So you're saying that the what was done in the narrow confines of Diffserv was
good enough, and that the problem is a matter of the broader architecture and
mechanisms for control and management?    Or should Diffserv have done more?
What do you suggest as next steps?

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 03 Jul 2002 14:22:52 +0200

>> I don't feel this is discouraging. It means that IETF is in general
>> doing a good job, because it tends to do very easy solutions.
>
> because its solutions are simple (regardless of how much complexity is
> needed to solve the problem) or because it does the easy bits and ignores
> the complex ones?
>

I think the first one. The complex solution will be propriatary anyway and 
only be standardized with big pressure from the market side.

>>
>> DiffServ is a good solution for a set of problem, but definitly not for
>> all QoS related solutions.
>>

Honestly it was not easy, and will never be.

> So you're saying that the next steps toward QoS should be in the context
> of NSIS, control/management architectures, etc.?

I am not sure whether NSIS can solve the difficult part (I currently don't 
see the willingness). But it will add another standard piece to the 
solution.

> characteristics.  What is it about point-to-point that requires a unique
> set of transfer characteristics, and what are they?
Yes, I means topology (without transfer characteristics). But we also 
looked into one-to-any type of services.

>> implementations and their calibration/configuration. We honestly don't
>> even use PHBs in their general specifications, however we also did not
>> look in the new EF spec too thouroughly.
>

I think PHB are underspecified.

>>
>>
>> >>
>> >>
>> >> > From the process we actually first looked into our implementation
>> >> > and then
>> hardware settings of some of the parameters such that we can provide a
>> set of PDB.)
>
> So in our taxonomy, many of your issues were really edge-to-edge service
> issues rather than PDB issues?  That is, we say that a PDB defines
> parameters, but does not specify their values.  In a service, the values
> are filled in.   Do you consider the former to be a significant issue, or
> are the problems only in the latter?

Might be a problem, but finally you have to fill-in the parameters and 
provisiong your network, and I do not care what you call PDB and what 
service.

>> >> different question, because some of the people are not able to
>> >> implement them with they DiffServ nodes.
>> >
>> Depends a little on what level you want to interooperate (router to
>> router, or network to network) he PDB I regard more a network to network
>> issues, and there the management and control plane are the more unsolved
>> problem.
>
> So you're saying that the what was done in the narrow confines of
> Diffserv was good enough, and that the problem is a matter of the broader
> architecture and mechanisms for control and management?    Or should
> Diffserv have done more? What do you suggest as next steps?

I agree here with Brian, lets wait an see if there really is a market. We 
should not further invest in standardizing technologies if they are not 
taking off.

Marcus