Subject: RE: [NSIS] Re: qos-nslp-00

From: "McDonald, Andrew" <[email-masked]>
Date: Fri, 3 Oct 2003 09:34:56 +0100

Hi Cheng,

Cheng Hong wrote:
> The model of operation in Figure 1 shows that the data flow would go
> through the "Outgoing Interface Selection (Forwarding)" block before
> entering the "Traffic Control" block. Does this mean that the traffic
> control in the model would only apply on the outgoing interface?

Figure 1 is only for guidance, to help give a visual idea of the different elements involved and their relationship to one another. It doesn't constrain the possible implementations. (Maybe an additional sentence is needed to clarify this.)

Since there is an implicit assumption that we are specifying QoS for a flow through the router, it makes sense to control the QoS for the two interfaces (input, output) together, i.e. once the output interface is known. A natural implementation would be to do as much as possible of the traffic control on the output interface, but this is not compelled.

In theory you could use a resource specification which separately defined the input resources and output resources, in which case it might be more natural to do traffic control in both places. (But you could still implement it all on the output anyway.)

> I noticed it's somehow different from the figure in RFC2205. Is this
> change intentional?

Yes, although it was originally based on Figure 1 from RFC2205, it is different. This is mainly to reflect the NSIS layer split, but also, hopefully, to improve clarity. Are there any particular elements that aren't clear, or need explaining?

Andrew

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

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 6 Oct 2003 11:40:05 +0800

Hi Andrew,

Thanks a lot for the detail explanation.

You are right that most of the implementations would choose to work only on
the output interface, since it's simpler. But, due to other considerations,
e.g. efficiency, etc, an implementation could choose to do it in a different
way. For example, one of the popular QoS implementations ALTQ
(http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ ) actually has
the traffic conditioner on the ingress interface in its DiffServ module.

Since the QoS-NSLP is meant to be agnostic to QoS models, I would prefer the
logical model also be neutral. Maybe some text for clarification is
necessary in the section. Or, could we do something like the RFC2205, where
the routing process is put at a position not implying the processing
sequence?

Best regards

Cheng

> -----Original Message-----
> From: McDonald, Andrew [mailto:[email-masked]]
> Sent: Friday, October 03, 2003 4:35 PM
> To: 'Cheng Hong'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Re: qos-nslp-00
>
>
> Hi Cheng,
>
> Cheng Hong wrote:
> Figure 1 is only for guidance, to help give a visual idea of the
> different elements involved and their relationship to one
> another. It doesn't constrain the possible implementations.
> (Maybe an additional sentence is needed to clarify this.)
>
> Since there is an implicit assumption that we are specifying QoS
> for a flow through the router, it makes sense to control the QoS
> for the two interfaces (input, output) together, i.e. once the
> output interface is known. A natural implementation would be to
> do as much as possible of the traffic control on the output
> interface, but this is not compelled.
>
> In theory you could use a resource specification which separately
> defined the input resources and output resources, in which case
> it might be more natural to do traffic control in both places.
> (But you could still implement it all on the output anyway.)
>
> Yes, although it was originally based on Figure 1 from RFC2205,
> it is different. This is mainly to reflect the NSIS layer split,
> but also, hopefully, to improve clarity. Are there any particular
> elements that aren't clear, or need explaining?
>
>
> Andrew
>
> --
> Registered Office: Roke Manor Research Ltd, Siemens House,
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is
> confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall
> not create or
> change any contractual relationship.
>
>