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

From: [email-masked]
Date: Fri, 18 Jan 2002 16:36:31 -0000

It doesn't really matter, but it isn't congestion control either. It is
traffic shaping.

If you don't have any QoS, and all users traffic is equal (in terms of
priority) then when a single user's traffic eats up "too much" of the buffer
space, then you throttle them back by using rate reduction. TCP does this.
SCTP uses other means.

Interesting though this is, I don't think that this is what NSIS is all
about.

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[email-masked]]
Sent: 18 January 2002 16:01
To: nsis
Subject: Re: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)

IMHO, this shouldn't be in NSIS scope. It is congestion control issue.
Of course, if one wants to do congestion control by tear-down and new
set-up of QoS call, he may use NSIS protocols :-)

-----Original Message-----
From: ext Giuseppe Bianchi [mailto:[email-masked]]
Sent: Friday, January 18, 2002 10:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)

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.

On Fri, 18 Jan 2002 [email-masked] wrote:

> 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

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

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