Subject: RE: [NSIS] summary of thread on data and signalling path

From: [email-masked]
Date: Thu, 31 Jan 2002 14:56:26 -0000

A good summary, and a clear way forward to be captured into a Requirements
document.

Dick

-----Original Message-----
From: David Partain [mailto:[email-masked]]
Sent: 31 January 2002 14:06
To: NSIS Mailing List
Subject: [NSIS] summary of thread on data and signalling path

Hi all,

Here I go again, trying to digest a Monster Thread...

The question posed is, "Do signalling and data need to follow the
same path in order to achieve what we're after with NSIS?"

Marcus started this thread by stating that he doesn't think this
should be a requirement.  I think we need to consider the
scenarios.

 - There are absolutely going to be cases where a centralized
   entity will take a decision about QoS requests.  In this
   case, there's no question there is no need to have data
   follow the signalling path.

 - There are absolutely going to be cases where there will _not_
   be a centralized entity managing resources and that the
   signalling will be used as a tool for resource management.
   For various reasons (such as efficient use of expensive
   bandwidth), one will want to have fine-grained, fast,
   and very dynamic control of the resources in the network.

 - There are going to be cases where there will be neither
   signalling nor a centralized entity (overprovisioning).
   In this case, the question posed just doesn't matter :-)

There are other possibilities as well.

Perhaps I'm being repetitive, but it's seems to me that the
important issue is that the domain answers the question,
"May I have what I want?"  Whether it bases the answer on a
centralized entity saying, "Sure, have a good time" or based
upon hop-by-hop verification of resource availability and then
allocation is not really important.  It's the combination of
domain answers which is important.

I think this follows very closely with what Ilya Freytsis wrote
on Tuesday:  "If you view the domain with a QoS technology
as a virtual router than NSIS signaling used between those
routers follows the same path as data. What happens within
the router is not a NSIS business."

As I see it, NSIS must accept all of these possibilities.
I also believe that we need to have standardized ways of
implementing both approaches, not just a domain-specific
free-for-all.    We need to define the interaction between
higher-level NSIS signalling that answers The Domain Question,
which I think will follow the same path as data, and the work
that's done within the domain to answer that question.

The NSIS protocol must be one of the options available for
managing QoS within a domain, but of course a different solution
can be chosen.  That solution may not require that user and
signalling data follow the same path.  However, if the NSIS
protocol is used within the domain, this may be required.

Cheers,

dlp

_______________________________________________
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: "Gary Kenward"<[email-masked]>
Date: Thu, 31 Jan 2002 11:23:08 -0500

I have been trying to stay out of this thread, but David triggered a
thought, perhaps one that simplifies the view of the problem.

At the IP layer it is inappropriate for us to attempt to take into
consideration bandwidth sharing issues. The main considerations of
bandwidth sharing are driven by the specifics of the link layer operation
more then protocol definition at the IP layer.

What should be a consideration, is whether the protocol has the ability
to be optionally routed along the same path as the data or a completely
or partially separate path. Ideally, the capability to route the protocol
along an independent path, would give the network designer/operator the 
option to manage bandwidth utilization through the topology.

One other, more minor observation, is we need to be very cautious about
solutions that build forwarding paths through the network, with state 
information at the nodes. This is the RSVP model, and it causes great 
grief for IP mobility solutions.

Gary

> Sent: January 31, 2002 09:06
> To: NSIS Mailing List

---

From: [email-masked]
Date: Thu, 31 Jan 2002 13:45:41 -0500

An additional issue associated with the same difficulty (though not mentioned in David's summary, but was raised on the mailing list before) is:

How can we actually perform bi-directional reservations when the forward and reverse paths are not reciprocal, with respect to routing topology and routing policy of network domains between sender and receiver? We have to have some baseline feasibility intuition while proposing requirements.

Hemant

-----Original Message-----
From: ext Michael Thomas [mailto:[email-masked]]
Sent: Thursday, January 31, 2002 11:55 AM
To: [email-masked]
Cc: NSIS Mailing List
Subject: [NSIS] summary of thread on data and signalling path

 >    follow the signalling path.

Has somebody shown, absolutely, how this centralized
thing understands an arbitrary routing topology between
the sender and receiver? What happends when it leaves
an AS?

	   Mike

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 31 Jan 2002 17:27:21 -0500

I think you are assuming an RSVP-like model, where the reservations
are made along the return path which is determined by the forwarding
path, and requires soft state storage. The need to ensure that the 
return path is the same as the forwarding path is one of the problems 
with RSVP, particularly in a mobile environment. This approach does
have a number of benefits, but isn't it too early to assume that it
is the approach for NSIS?

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: January 31, 2002 13:46
> To: [email-masked]
> Subject: RE: [NSIS] summary of thread on data and signalling path
> 
> 
> An additional issue associated with the same difficulty 
> (though not mentioned in David's summary, but was raised on 
> the mailing list before) is:
> 
> How can we actually perform bi-directional reservations when 
> the forward and reverse paths are not reciprocal, with 
> respect to routing topology and routing policy of network 
> domains between sender and receiver? We have to have some 
> baseline feasibility intuition while proposing requirements.
> 
> Hemant
>

---

From: [email-masked]
Date: Thu, 31 Jan 2002 19:20:28 -0500

Hi Gary, I am not referring to the problem you are talking about (though I agree that it is one of the serious shortcomings of RSVP when used with Mobile IP). I am talking about bi-directional data streams, where the packet paths in two directions are different.  - Hemant
 
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 31, 2002 5:27 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Subject: RE: [NSIS] summary of thread on data and signalling path

Gary 

> From: [email-masked] [ mailto:[email-masked]] 
> From: ext Michael Thomas [ mailto:[email-masked]]