Subject: [NSIS] Dave Oran's comments

From: [email-masked]
Date: Mon, 1 Mar 2004 13:39:07 +0200

These are Dave Oran's comments.

thanks,
John

This covers my overall impressions and my comments on GIMPS. Comments on 
QoS and NATFW to follow.

General:
- I'm still not comfortable with the delicate tradeoffs of responsiveness 
to routing changes and message overhead. This is fundamental to the whole 
C-mode/D-mode operation and hence we may just have to live with the 
tradeoffs
- Don't feel comfortable that the ordering properties among the signaling 
applications carried by GIMPS are captured in the design. For example, QoS 
signaling depends on prior establishment of NAT and FW state. What enforces 
this ordering, and if so, does it require extra RTTs to set up the 
dependent state?

NTLP Comments:

- Definition of data flow excludes multicast. OK, but should this be part 
of  the definition?
- Definition of data flow enforces "unique path". Does this mean path 
splitting is not ok even for flows where delivery order doesn't matter?
- How does path coupling work if proxies are not on the path?
- What led to the decision to use a hop count rather than a VIA-style path 
recording?
- The D-mode gimps message needs to truly mimic the actual data flow in 
order to guarantee congruent routing. This is particularly important where 
routers may be doing their own flow routing based on things like DSCP.
- If NATs have to be GIMPS-aware then aren't we punting a big part of the 
application scope for NSIS?
- NIT on tunneling - it's the outer header of the tunneled packets which 
doesn't have RAO, not the tunneled packet itself.
- section 8.3 says raw IP ruled out by section 8.2 but I see nothing in 8.2 
which argues for ruling out raw ip encapsulation. Just confused here...
- small point on aggregation - its the exit interface which defines the 
aggregation level, not the router. A router could have interfaces at 
different aggregation levels.

Comments on NSLP

- in general this doc is not as well written as NTLP and needs some 
editorial work. Parts are pretty hard to understand.
- Policy control may involve "envelope resource utilitzation" policy in 
addition to simple AAA. This means that hard synchronization with the AAA 
policy state and the NSLP element may be necessary.
- Is there a need for explicit teardown invoked by the AAA element?
- How is receiver selection based on ADSPEC done if resources are reserved 
in the forward direction with RESERVE?
- some talk about 2-phase operation for RSVP. Any thought of the same for 
NSLP?
- Didn't see any way to do resource sharing across flows.
- Ditto for fate-sharing across flows (if you tear one down you tear the 
fate-shared ones down)
- Reservation priority is declared out of scope but is critically 
important. We can't just punt this. One thought is to have it be part of a 
set of "common facilities" that go across all the GIMPS applications. I bet 
there are a number of such common things which are not part of the 
transport but aren't specific to a particular signaling appication.
- Is there any capability for make-before-break so that reservations can be 
installed on multiple paths at the same time to deal with graceful 
mobility? It seems that the notion of flow/session separation captures part 
of this, but I don't see how it solves the double-booking problems on the 
common links.
- how does bi-dir reservation enforce symmetric routing?

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 Mar 2004 05:09:07 -0000

Dave, all,

Many thanks for these comments.

I've made some (brief) replies on the specific NTLP issues
below. Mostly I think these are clarifications, but in some
cases there will need to be some more detailed work. (I think
John will capture these bigger points somehow and we'll work
out how to address them.)

There is a general question: a number of these questions
really ask for more design rationale to be recorded about
the protocol. Where is the right place to put this?

> NTLP Comments:
> 
> - Definition of data flow excludes multicast. OK, but should 
> this be part of the definition?

We could rephrase the text in section 2 to say that flows can
be uni/multi/any-cast but that our scope for this document is 
restricted to unicast flows. And maybe put the scoping stuff
further up in section.

> splitting is not ok even for flows where delivery order 

My current assumption is: yes, unfortunately.
It would (probably) be possible for GIMPS to find most or all of 
the branches of a split flow path. However, it would be hard to
work out what to tell the NSLPs about this situation - would it
be necessary (for example) to estimate traffic percentages on 
each branch and so on.

So, a first guess (in the interests of simplicity) is to just
to say 'NSIS won't give the full picture if path splitting
happens'.

This could change if
- we start to think path splitting is a more common problem
- we think it's easy to tell the NSLPs something sensible
(it's easier for NATFW than QoS).

More feedback on either of these (from anyone) would be helpful.

> - How does path coupling work if proxies are not on the path?

It doesn't; or rather, we only consider proxies that are on
the path. This can be fixed in section 2.

> - What led to the decision to use a hop count rather than a 
> VIA-style path recording?

That's something that hasn't been analysed in detail, IIRC.
There may be a question about where between the layers loop
prevention and path recording should be done in general.

(So, I suspect we should make an action to analyse this
for the next version.)

> - The D-mode gimps message needs to truly mimic the actual 
> data flow in order to guarantee congruent routing. 
> This is particularly important where 

This is quite right. We could emphasise this more in the
text (i.e. explain the motivation). Probably the right place
would be 5.3 (it already comments on setting the DSCP to
address this problem), with some more information on how
things can go wrong if higher layer routing is done.

> - If NATs have to be GIMPS-aware then aren't we punting a big 
> part of the application scope for NSIS?

There are different levels of 'awareness'. The minimal level
of awareness that is needed is for a NAT to know that a 
particular packet has header field information inside it
and that something should be done to add some further 
information about existing bindings or say there are no
applicable bindings.

This is a lot less than the full set of features that
a NATFW application might/should have. Precisely where the
division of responsibility between GIMPS and the NATFW 
should be is still open.

> - NIT on tunneling - it's the outer header of the tunneled 
> packets which doesn't have RAO, not the tunneled packet itself.

True.

> - section 8.3 says raw IP ruled out by section 8.2 but I see 
> nothing in 8.2 which argues for ruling out raw ip encapsulation. Just 
> confused here...

Basically they are NAT traversal issues.
- Raw IP (according to several reports) won't go through 
  some (many?) existing low end NATs. This would seem to be
  a show stopper.
- If you are in an address sharing scenario, there needs to
  be some other identifier to demultiplex messages into the
  internal network. Using UDP provides the port number,
  but with a raw encapsulation GIMPS would have to provide 
  its own.

We could spell this out in more detail (and then people could
say if this is enough to draw a conclusion).

> different aggregation levels.

True. And there could be different levels for different
applications (and it could get more complex still). We can
extend 8.4 to address this.

Thanks again,

Robert H.