Subject: RE: [NSIS] Two kinds of requirements (unsupported domains + chi c k en and eggs)

From: [email-masked]
Date: Mon, 21 Jan 2002 09:59:43 -0000

I don't want to get into the business humanity and all the scenarios that it
entails, but I am not convinced it is quite as bad as you suggest. Most of
these things are covered by business agreements and contracts - if there is
an agreement or contract and one provider doesn't meet it, then you get the
service from another.

There are more problems that I have since thought of. What happens if the
service provider gets a request for a high-grade connection - which can only
be satisfied by downgrading a stream that had been established already at
the requested level/class?

We could solve this, with a "no established flow downgrading" requirement or
option, but do we want to?

Dick

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: 21 January 2002 09:40
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chic k en and eggs)

> I agree that it is the user that makes the decision about a 
> chunk of network that cannot support the requested QoS.
> 
> But why mark the packet and continue on all the way to the 
> destination and back? It is simpler for a user to indicate
> in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.

Case 3 probably results in Best Effort should you apply at inter carrier
interfaces. I mean, it's a competitors reservation and the competitors
customer sees what he's getting from his provider (because he doesn't know
that I am the bad guy...).
Ok, I may have expressed it extremely negative, but did I really fail to
describe business humanity? I would suggest to leave no room for negotiation
and interpretation at inter carrier interfaces. 

This option may be allright at the first/final customer - provider edge. But
it should be limited to this interface.
I personally look at negotiation only as an optional feature. To me, it's
not a requirement.

Regards, Rüdiger

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jan 2002 11:29:00 +0100

Hi Dick,

comments in line.

Regards, Rüdiger

> I don't want to get into the business humanity and all the 
> scenarios that it entails, but I am not convinced it is 
> quite as bad as you suggest. Most of these things are
> covered by business agreements and contracts 
> - if there is an agreement or contract and one provider
>   doesn't meet it, then you get the service from another.

I've been doing technical inter carrier agreements a while ago. I certainly don't want to say that carriers are not interested in providing end to end QoS services and I am aware of the contractual issues around them.

If you look at inventions like e.g. "hot potato"/"cold potato" routing, it may not be desirable to allow softening up a service committment already while specifying the service.

But also as a technican who has been doing this kind of inter carrier negotiation already: please let's limit the number of options with regard to QoS negotiation at inter carrier interfaces to an absolute minimum. And it not only simplifies life, it is also in the sense of the customer. 
 
> There are more problems that I have since thought of. What 
> happens if the  service provider gets a request for a 
> high-grade connection - which can only be satisfied by
> downgrading a stream that had been  established already at
> We could solve this, with a "no established flow downgrading" 
> requirement or option, but do we want to?

Sounds a bit like preemption. In theory preemption is a good idea. In practice, it adds signalling requirements (check the DiffServ aware Traffic Engineering discussion for input) and it results in added complexity in operation. 
In your example, a "resources not available" message may be the outcome (if signalling and operation of services are to be kept simple and preemption is not supported).

---

From: Yaron Kahana <[email-masked]>
Date: Mon, 21 Jan 2002 15:09:49 +0200

Hi Duediger,

>If you look at inventions like e.g. "hot potato"/"cold potato" 
>routing, it may not be desirable to allow softening up a service 
>committment already while specifying the service.

What should happen in "a hard commitment" was given by the network, but the
network "doesn't walk the talk", i.e. does not fulfills its commitment? Do
you require the application to actually verify the level of service? do you
think it should happen in a very low probability (what is "low" here?)?

Regards,

Yaron Kahana
COGITO Project Manager
ComGates Ltd.
Email: [email-masked]
Visit Us: www.comgates.com
COMGATES - Powering the NGN

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jan 2002 14:37:45 +0100

Dear Yaron,
 
>> committment already while specifying the service. 

Y> What should happen in "a hard commitment" was given by the
Y> network, but the network "doesn't walk the talk", i.e. does
Y> not fulfills its commitment? Do you require the application
Y> to actually verify the level of service? do you think it 
Y> should happen in a very low probability (what is "low" here?)?

If the required resources are unavailble during reservation set up, a "busy" signal is appropriate. In my view (service specific) network planning and provisioning are the tools to prevent busy signals, not softened up service specifications.

If a service quality is temporary degraded while a reservation is active, usually a definition for unavailability is fixed by a contract. 

Regards, Rüdiger