Subject: RE: [NSIS] Alternatives for supportingdomain-localadmissioncontro loperation in NSLP/QSPEC

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 13 Nov 2006 12:12:33 -0500

Georgios:

This is only true for the standard-based IETF QOS Models (RSVP, IntServ,
and DiffServ). 

All other so-called QOS models (non-standards DSTE, Y.1541, and
3GPP/Y.1541) have no concept of Token Bucket as they do not have QOS
signaling messages defined of their own other than some values of
delays, jitter, and packet losses. It happens to be, like all SLAs,
these implementation-specific value-based QOS models can also be mapped
into DiffServ QOS messages.

The value-based QOS models are ONLY applicable for implementation
agreements (e.g., OSP). For example, some specific values of some
parameters of DiffServ need to be agreed among some implementers or
ISPs, and they will develop SLAs for this. This does not mean we will
include all SLAs of the whole world as a part of this "generic" standard
QSPEC RFC.

In this respect, specific value-based QOS models like DSTE, Y.1541, and
3GPP/Y.1541 are nothing but some value-based QOS parameters of "service
level agreements (SLAs).

If needed, any reference to DiffServ QOS model also needs be taken off
from this standard-track RFC. The token bucket is good enough to be used
by DiffServ, RSVP, and IntServ as they are the QOS models per standards
and have their own QOS signaling messages that will provide
"interoperability."

This standard track RFC even does NOT need to include any references to
DiffServ QOS model as well. Again, if all SLAs are mapped into DiffServ,
that does not mean all implementation-specific value-based SLAs are QOS
models and then we should start including one SLA after another into
this standard track RFC. The inclusion of DiffServ QOS model seems to us
as a "ploy" for inclusion of other SLA-type QOS things.

What does "force" the NSIS WG to "mess" the whole standard-track RFC
after all these hard works "forcing" the same non-interoperability
issues mixing between apples and oranges in the same draft?

Why does the NSIS WG not write separate individual draft for each QOS
model (RSVP, IntServ, DiffServ, DSTE, Y.1541, 3GPP/Y.1541) how to use
the QSPEC using NSIS QOS signaling messages?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Monday, November 13, 2006 11:33 AM
To: [email-masked]; 'Ash, Gerald R (Jerry), ALABS'; 'Roland
Bless'; 'David R Oran'
Cc: 'NSIS Group'
Subject: RE: [NSIS] Alternatives for
supportingdomain-localadmissioncontroloperation in NSLP/QSPEC

Hi Roy

There are nomore interoperability issues since the only parameter 
that can be considered as mandatory is the Token Bucket parameter, 
which is used as the traffic source description.

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: maandag 13 november 2006 17:08
> To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; 
> Roland Bless; David R Oran
> Cc: NSIS Group
> Subject: RE: [NSIS] Alternatives for supporting 
> domain-localadmissioncontroloperation in NSLP/QSPEC
> 
> Georgios and all:
> 
> The fact is that all QOS model-specific extensions, 
> explanations, and references MUST be DROPPED per consensus of 
> this IETF meeting.  
> 
> In this way, the problems of all NON-interoperability among 
> the standard-based IETF QOS models (RSVP, IntServ, and 
> DiffServ) and so-called "private" non-IETF, non-standard QOS 
> models (Y.1541 and
> 3GPP/Y.1541) will be avoided in this standard-track "generic" 
> QSPEC RFC.
> 
> If anyone wants to avoid this consensus of the IETF meeting, 
> they MUST come up with the technical proposal how to solve 
> the NON-interoperability problems among the standard-based 
> IETF QOS models (RSVP, IntServ, and DiffServ) and so-called 
> "private" non-IETF, non-standard QOS models (Y.1541 and 
> 3GPP/Y.1541). If brute forces are used to add any references 
> of QOS model-specific things as the present draft stands, the 
> consensus of the IETF will be broken and the draft will NOT 
> move for IESG approval as we will be again going to the 
> circle of interoperability issues.
> 
> Best regards,
> Radhika
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Georgios Karagiannis
> Sent: Monday, November 13, 2006 6:57 AM
> To: 'Ash, Gerald R (Jerry), ALABS'; 'Roland Bless'; 'David R Oran'
> Cc: 'NSIS Group'
> Subject: RE: [NSIS] Alternatives for supporting 
> domain-localadmissioncontroloperation in NSLP/QSPEC
> 
> Hi Jerry
> 
> I agree with you!
> I think that we now have reached a consensus on all open 
> issues and we can proceed on finalizing all NSIS base drafts!
> 
> Best Regards,
> Georgios 
> 

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 13 Nov 2006 18:35:31 +0100

Hi Radhika

The optional parameters are just included to simplify the 
parameter encoding that can be used by the QoS models supported by NSIS.
Suppose that a QoS model needs to use the PHB class as parameter, then
instead of 
reinventing its own encoding for this parameter, the encoding 
provided in the QSPEC template draft can be used.

Thus, the QSPEC template provides guidelines on how the encoding of such
parameters 
should be accomplished. I think that this is something usefull!

Best Regards,
Georgios

> Sent: maandag 13 november 2006 18:13
> To: Georgios Karagiannis; [email-masked]; Ash, Gerald 
> R (Jerry), ALABS; Roland Bless; David R Oran
> Cc: NSIS Group
> This is only true for the standard-based IETF QOS Models 
> (RSVP, IntServ, and DiffServ). 
> 
> 3GPP/Y.1541) have no concept of Token Bucket as they do not 
> have QOS signaling messages defined of their own other than 
> some values of delays, jitter, and packet losses. It happens 
> to be, like all SLAs, these implementation-specific 
> value-based QOS models can also be mapped into DiffServ QOS messages.
> 
> The value-based QOS models are ONLY applicable for 
> implementation agreements (e.g., OSP). For example, some 
> specific values of some parameters of DiffServ need to be 
> agreed among some implementers or ISPs, and they will develop 
> SLAs for this. This does not mean we will include all SLAs of 
> the whole world as a part of this "generic" standard QSPEC RFC.
> 
> 3GPP/Y.1541 are nothing but some value-based QOS parameters 
> of "service level agreements (SLAs).
> 
> If needed, any reference to DiffServ QOS model also needs be 
> taken off from this standard-track RFC. The token bucket is 
> good enough to be used by DiffServ, RSVP, and IntServ as they 
> are the QOS models per standards and have their own QOS 
> signaling messages that will provide "interoperability."
> 
> This standard track RFC even does NOT need to include any 
> references to DiffServ QOS model as well. Again, if all SLAs 
> are mapped into DiffServ, that does not mean all 
> implementation-specific value-based SLAs are QOS models and 
> then we should start including one SLA after another into 
> this standard track RFC. The inclusion of DiffServ QOS model 
> seems to us as a "ploy" for inclusion of other SLA-type QOS things.
> 
> What does "force" the NSIS WG to "mess" the whole 
> standard-track RFC after all these hard works "forcing" the 
> same non-interoperability issues mixing between apples and 
> oranges in the same draft?
> 
> Why does the NSIS WG not write separate individual draft for 
> each QOS model (RSVP, IntServ, DiffServ, DSTE, Y.1541, 
> 3GPP/Y.1541) how to use the QSPEC using NSIS QOS signaling messages?
> 
> Best regards,
> Radhika
> 
> To: [email-masked]; 'Ash, Gerald R (Jerry), ALABS'; 
> 'Roland Bless'; 'David R Oran'
> Cc: 'NSIS Group'
> There are nomore interoperability issues since the only 
> parameter that can be considered as mandatory is the Token 
> Bucket parameter, which is used as the traffic source description.
> 
> Best regards,
> Georgios
> 
> 
> 
> explanations, and 
> > references MUST be DROPPED per consensus of this IETF meeting.
> > 
> > In this way, the problems of all NON-interoperability among the 
> > standard-based IETF QOS models (RSVP, IntServ, and
> > DiffServ) and so-called "private" non-IETF, non-standard QOS models 
> > (Y.1541 and
> > If anyone wants to avoid this consensus of the IETF 
> meeting, they MUST 
> > come up with the technical proposal how to solve the 
> > NON-interoperability problems among the standard-based IETF 
> QOS models 
> > (RSVP, IntServ, and DiffServ) and so-called "private" non-IETF, 
> > non-standard QOS models (Y.1541 and 3GPP/Y.1541). If brute 
> forces are 
> > used to add any references of QOS model-specific things as 
> the present 
> > draft stands, the consensus of the IETF will be broken and 
> the draft 
> > will NOT move for IESG approval as we will be again going to the 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Georgios Karagiannis
> issues and we 
> > can proceed on finalizing all NSIS base drafts!
> > 
> > Best Regards,
> > Georgios
> > 
> 
> 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 13 Nov 2006 13:18:51 -0500

Georgios:

I think that we understand each other clearly and have agreement as
well. What we differ is where and how the works need to be done.

Kindly see Inline [RRR]

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 12:36 PM
To: [email-masked]; 'Ash, Gerald R (Jerry), ALABS'; 'Roland
Bless'; 'David R Oran'
Cc: 'NSIS Group'

Hi Radhika

[RRR] The "generic" texts without referring any particular QOS model as
stated above are always OK for this "generic" RFC.

[RRR] Again, it is also OK per principles stated above. However, it is
NOT OK, to provide some extensions of some specific QOS models as a part
of this generic standard track RFC. It is out-of-scope for this RFC.

[RRR] Moreover, the inflexible tightly integrated DSTE, Y.1541, and
3GPP/Y1415 value-based QOS classes are so problematic that it will
almost non-usable for any practical purposes unless some extensions in
QOS signaling messages are created for them as they do not have any
signaling messages of their own. In fact, they do not need one because
all they want to send some values. What it means that any references of
these QOS models with some extensions here and here are also incomplete.
In all cases, a separate draft is needed for each of these Value-based
QOS models.

[RRR] The question is this: Why do then these editors use brute forces
for inclusion of DSTE, Y.1541, and 3GPP/Y1415 in this draft? The answer
is this: To obtain some quasi-legitimacy of being standards - to be
accepted by the whole world. As a result, the non-interoperability has
become mandatory. Why should NSIS WG pay the price of
non-interoperability?

Thus, the QSPEC template provides guidelines on how the encoding of such
parameters 
should be accomplished. I think that this is something useful!

[RRR] Encoding of QSPEC template for each QOS model needs to be done in
separate individual drafts as described above. Definitely it is the most
useful part for creating standards. There are a lot of works involved:
End-to-End negotiations and detail call flows. If you want deal with all
those things in this RFC, let us include these things in this generic
draft!!! Indirectly, interoperability issues will also come. Do you like
to include this as well?

[RRR] The way end-to-end negotiations to be done in RSVP, IntServ, and
DiffServ will be fundamentally different from those of the value-based
DSTE, Y.1541, and 3GPP/Y.1541. On the top of this, you can use SIP as an
example application. You can how the complex the QOS signaling message
flows is. However, we have no problems with RSVP, IntServ, and DiffServ.

[RRR] Conclusion: It is not that we cannot include some encoding related
to some QOS-specific models, but these need to done separately with due
examples and detail call flows. That is why, any specific references to
any QOS models will be "incomplete" and will create more questions than
answering them in this generic QSPEC RFC.

Best Regards,
Georgios