Subject: RE: [NSIS] question for clarification

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 6 Aug 2002 10:32:16 +0200

Marcus,

you are absolutely right, let's keep signaling for resources
separated from signaling for routing.

Regards, Rüdiger

>> Questions:
>> should we do anything special in the signalling protocol 
>> to force or prefer the same path?
 
> That is exactly what I don't want to do. If the protocol works 
> bi-directional on the same path due to topological constraints
> this is fine. But finding the same path is IMHO a routing 
> issue. I pretty much like the decoupling of routing and
> signaling.

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

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 6 Aug 2002 11:42:22 -0400

Hi Dan, all

I think Dan making good arguments for the NSIS support of the optional
modalities of bi-directional reservations. Since their value as well as
complexity probably depends on the part of the network it should be
thoroughly analyzed and reflected in the section 6 of the Marcus' draft.

Regards,
Ilya

-----Original Message-----
From: Dan Grossman [mailto:[email-masked]]
Sent: Tuesday, August 06, 2002 10:31 AM
To: Hancock, Robert
Cc: [email-masked]; jkchoi; Shahrier, Sharif M.; [email-masked]
Subject: Re: [NSIS] question for clarification

"Hancock, Robert" wrote:

> hi dan, all,
>
> some points:
>
> firstly, i've long had a background assumption that it was not the role of
NSIS as a transport protocol to influence/force/modify packet paths.
Resource messages carried by NSIS might do this as a side effect, but NSIS
itself has to be able to work in arbitrary environments (possibly taking
advantage of special characteristics of those environments, of course).

Why not?  There are cases where the originator of a flow has a (small 'p')
policy objective,  like "I'd rather use service provider 'x' than service
provider 'y'", or "Please constrain this bidirectional flow to use reverse
paths" or "Please route these two flows as diversely as possible".  I don't
think that there are very many of these cases, but I don't see any
architectural reason to preclude them.

>
>
> on the other hand, i've been involved in enough conversations to realise
that this assumption is not universally held (maybe i'm even in the
minority). in any case, we should probably state something more concrete.
>
> so, my take on dan's questions:
> a) no, NSIS shouldn't do things to force/prefer symmetric routing

The more we discuss this, the more inclined I am to believe that the
mechanisms to do so should be put in place, as long as the network has the
right of refusal.  You could do it with preference ("I prefer reverse
paths") and/or you can do it with source directed blocking ("If you can't or
won't give me reverse paths, please reject the flow, I don't want it").

>
> b) if there are good low-overhead ways to discover topological constraints
i don't see why we shouldn't exploit them. the most important constraint
would be that a host knew it was connected to the network over a point to
point link.

Actually, that's "connected to a stub network".

>
> c) i doubt that a bidirectional reservation would be simpler than
individual unidirectional ones, rather you could do grouping to get the same
effect with very little extra complexity. (i think this is essentially what
packetcable does.) i think the current requirements encourage this as a
possibility to the right extent already, however.

I believe that the point in PacketCable was to reduce signalling latency and
message overhead by exploiting the fact that the cable subnet is a stub
network.   It also simplifies recovery from cases where the flow in one
direction can't be set up,  making having a flow in the other direction not
useful.  If bi-directional flows are dominant, deadlocks can occur
unless there is some atomic way reserve resources for both directions.

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 6 Aug 2002 16:41:33 -0400

Melinda,

I disagree with your judgment that Dan's proposal "telling" how to route
packets. It is about NSIS being able to ask network the following question:
"Based on the topology/routing knowledge that you have could you please
(preferably) allocate resources that satisfy the certain conditions."

I do not see how will it effect routing in the negative ways that you have
mentioned and why does it go against IP philosophy. I am not convinced that
VoIP and TRIP is an adequate analogy here.

Regards,
Ilya

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, August 06, 2002 3:21 PM
To: Dan Grossman
Cc: Melinda Shore; [email-masked]
Subject: Re: [NSIS] question for clarification 

> It sounds like you're trying to articulate an architectural principle,
> but I don't understand what it is or how you justify it.

Put a packet into the network with a valid destination
address and allow IP-layer routing to determine how it gets
from here to there.  If applications start determining
routes for traffic, you run into problems like suboptimal
routes, tromboning, and so forth, and you can only avoid
those by pushing routing state into the applications
themselves.  That starts to interfere with network
robustness (recovery from outages, convergence after routing
changes, etc.)  and greatly increases the complexity of both
the network and the application.

> Nobody's talking about adding a routing protocol:  we've got too many of
> them already.

Sure you are.  If you're telling the IP layer how to route
packets, you're a routing protocol.

> And certainly there are precedents in IP for requesting
> particular routing treatments (source routing and the security field
> come immediately to mind).

You'll note that source routed packets are usually dropped.
I'm not sure what you mean by "security field" - are you
referring to the DS byte?  That's an in-band signaling
mechanism, not a routing mechanism.

> I don't understand why you'd need an upper layer routing protocol for
> this or why there's so much of a separation of concerns that would
> warrant creating a new layer.

It's generally appropriate to route among entities at the
same layer.  So, for VoIP the signaling problem is how to
route to appropriate gateways, not how to choose the routers
the traffic will traverse en route.  For content networking
it's how to find the appropriate cache.  And so on.  That's
one aspect of "layer."  The other layering question is
related to the NSIS protocol itself.  There appears to be
widespread agreement that the NSIS protocol will be split
into two layers; one providing the NSIS transport and
protocol machinery and the other providing the data
representing the NSIS request (see Bob Braden's two-layer
draft).  This provides greater generality/power in the base
protocol and resolves some of the weaknesses that prevent
RSVP from being a more general-purpose signaling protocol.
It seems clear to me that to the extent that routing should
be treated as an NSIS function, and I'm not convinced that
it should, it belongs in the upper layer, not the transport,
and we're not working on the upper layer yet.

Melinda

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 21 Aug 2002 16:11:29 -0400

I had just returned from vacation, thus have not been keeping up with the
mailing-list.

I have some comments.

c) i doubt that a bidirectional reservation would be simpler than individual
unidirectional ones, rather you could do grouping to get the same effect
with very little extra complexity. 

I presented a bi-directional reservation scheme at the last IETF meeting. It
showed that there is a reduction in the number of signaling messages in
bi-directional reservation compared to individual unidirectional ones. Thus,
clearly bi-directional should be simpler, with less overhead.

Sharif.