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

From: [email-masked]
Date: Fri, 18 Jan 2002 14:03:23 -0000

I think that you agree with me but didn't quite understand what I was
suggesting.

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.

Then you can set up the connection in one go.

It is also slightly better, if you accept (and we haven't discussed this
yet) that the choice of route can be influenced by the requested QoS. If the
user has marked 1 (above) you might route differently to 2 or 3, as an
alternative to just failing the connection.

Dick

-----Original Message-----
From: Giuseppe Bianchi [mailto:[email-masked]]
Sent: 18 January 2002 13:36
To: [email-masked]; blefari
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)

Extending Dick's comment:

On Fri, 18 Jan 2002 [email-masked] wrote:
> [...]
> The protocol reaches a node at the edge of a domain/network (aneveryedge
> node) and knows that the best routing from here is through a chunk of
> besteffort (the routing tables tell it so). The node needs to decide
whether
> or not to progress or to refuse. This gives us a requirement on the
> protocol: we need to include a class that says "I'd rather get my comms
link
> up with a reduced QoS than get a refusal". We also need a class that says
> "don't down downgrade me" or "don't down downgrade me below [classX]". If
it
> does progress across this network domain, we can still signal into the
next
> NSIS-aware domain (as I am hoping the domain without support can still
route
> packets).
> Note: Best effort means that there are no guarantees because NSIS is not
> supported. It might be overprovisioned and providing a superior service,
but
> it doesn't have a CAC.

Why leaving this decision up to the node? An alternative (which may
actually coexist with Dick's idea) is to use a form of marking, and take
back to the user the information that one domain along the path is Best
Effort... Depending on its requirements, the user will know whether to
progress or to refuse.

On a more general point of view, and in the spirit of the Internet, I'd
recommend to keep as much as possible the intelligence at the edge of the
network. In this sense, NSIS should be designed as a protocol that allows
end nodes to discover the state of the nodes/domains along the path and to
react accordingly.

To make a simple example: I need to set up a call with some requirements.
I (or my access router) send an NSIS signalling packet including some form
of specifications & requirements. This packet is locally handled by each
network node (domain) as follow: if the node (domain) can guarantee the
reqs, it just forwards the NSIS packet along; If it cannot guarantee the
reqs, but it can accept the request with some downgraded form of of
support, it marks the packet; if, finally, it cannot accept the request,
it just says no (by, e.g. suitably marking the NSIS packet, or, as we
suggested in an earlier internet draft to make this idea compatible with
DiffServ domains, blocking it - timeouts at the end points will do the
rest). When the NSIS signalling packet gets back to the sender, it
contains all the relevant information to proceed.

Giuseppe Bianchi
[email-masked]
http://cerbero.elet.polimi.it/people/bianchi

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

---

From: Giuseppe Bianchi <[email-masked]>
Date: Fri, 18 Jan 2002 16:50:11 +0100 (MET)

Right, I had misread your email, and I definitely agree with your solution
when specifically dealing with connection setup.

Indeed, if we consider using NSIS refreshes as a mean to allow
application's adaptation (e.g. rate reduction), some forms of feedbacks
from the network via packet marking appear necessary (actually, is this
issue within the scopes of NSIS?)

Giuseppe.