Subject: [NSIS] Minutes from Tuesday

From: [email-masked]
Date: Wed, 19 Feb 2003 16:20:29 +0200

NSIS interim meeting (Tuesday February 11) 

Attendants: 

Scott Bradner, John Loughney 

Marcus Brunner, Ruediger Geib, Hans Lippitsch, Hannes 
Tschofenig, Henning Schulzrinne, Robert Hancock, Kwok Ho Chan, Ping Pan, 
Joachim Hillbrandt, Janne Rinne, and others

Minute Taker: 

Hannes Tschofenig; Sven van den Bosch

Agenda:

The Design Space for NSIS signaling protocols (Henning)

My NSIS model

NSIS assumptions:
- we want to support more than a single application
- operating definition of nsis: path associated state management
- possible applications: 
	* traceroute
	* active networking
	* network property management/middlebox communication

- functionality which should be supported: 
* bi-directional signaling support
* signaling must be done possible between only some nodes (for repair, etc.) / supported in RSVP but only to some extends - no generic mechanism

Finding NSIS peers

we do not want to find all nsis peers along the path
goal : find next node along the path

scott: rsvp makes the assumption that every node along the path supports rsvp

robert: another category is not only to find an nsis node but also to find a node which supports a specific functionality
henning: do we want to provide short-cuts or not?

marcus: explit route object is a externally configured mechanism to avoid discovery (external path knowledge)
scott: the addresses could be any cast addresses

When to discover peers

Who triggers a discovery procedure?  (NI, NF)
a) Discovery triggered by NI (requested)
b) Discovery independently at nodes along the network (more traffic but faster reaction time)
e.g. when a route change in the middle is detected.

scott: soft state is important
agreement by everyone - transport connection does not violate this principle

henning:
refresh reduction extension allows you to extend the refresh interval by separating the overloaded functionality of the path message
should the soft state time be configurable?

scott: cbr type of exclusive reservation disallows other nodes to use data traffic 
henning: also regular reservation disallows other nodes to make a reservation

henning: automatic discovery is not always what we want. (example: remove state) / this, however, requires further thoughs.

triggered updates in rsvp are only partial useful

three types of route changes
a) observable and meaningful (next nf node is different)
b) observable and not meaningful (possible in an edge model) - not useful to track it
c) non-observable (not immediately)

Next-node discovery

this is the most significant difference between path coupled and path decoupled 
the only useful notion for path-decoupled procedure is about the notion of ASes

discovery is an approximation
problems might be caused by load balancing, policy routing, layer 4 load balancing, etc.

there are problems for any type of policy based forwarding and implicit/explicit discovery procedures (path-coupled)

scott: load balancing is even worse since it makes a hash over a fixed portion of the header (including protocol type)

conclusion: let's use the destination address inside the ntlp - load balancing problems always causes problems (i.e. use a simple solution)

Transport Requirements

possible large data volume and large number of messages

henning: minimal nsis application requirements - path -associated state management
scott: "traceroute++" would be an application which is at least required by some people
henning + john: we should not close too many doors to prevent some solution.
john: we should make it very generic
scott: as a summary: there are things that are larger than mtu
henning: see sip as an example 

henning: there are two issues - large objects / high bursts
scott: congestion control is very important

Upper/Lower Layers

do all nodes process the messages?
depends what information is located where

scott: extensibility should be provided (see something which i do not know - i should not fail)

scott: see ipv6. some bits which tell what you do when the message is received but not understood

there has been some confusion what the term NTLP means.
henning's definition: ntlp is on top of udp, tcp or some other reliable transport mechanism

Reliability

fast and reliable setup because human factor is involved.

(some issues are only relevant for the initial signaling messages)

Options:
a) end-to-end 
* roundtrip estimate is fairly poor
* node processing adds unpredictable variability (e.g. aaa processing).
  (for end-to-end processing you don't have only transmission delay)
b) peer-to-peer  
* better rtt
*re-use transport optimizations (sack)
* mandates explicit discovery

Other transport issues

the signaling message can get bigger along the path (add / modify / delete)
designing a new transport protocol is very difficult

Options for transport protocols:
- raw ip
- tcp
- sctp
(see ieee network hol/ sctp)
john: multiplexing capability is the big advantage of sctp not the hol
scott: multiplexing was the reason to create sctp (not hol)
john: sctp has the same order of performance characteristics as tcp
scott: the best things learned from tcp have been added to sctp
further protocols:
- ddp (udp+congestion control)
- dccp 

transport protocol issues have no relationship to soft-state principle
optimization issue: state maintenance / state establishment
(local optimization issue whether to keep a transport layer session alive or to close it)

multicast: 
even in rsvp nearly all messages are unicast (except for path)
end-to-end principle: not clear what "end" in this context means
henning: nsis is not just message forwarding protocol (like beep) / it is about adding/modifying/deleting objects along the path
scott: it is not modifying the data stream
georgos: is ntlp and nslp always co-located?

State overhead

you are keeping the same information with and without transport layer protocol
transport protocol implementation: mostly a non-issue
transport header overhead: more with transport protocol overhead

Identifiers should be....
(a summary of henning's thoughs)

- we need something
- do not overload identifiers
- should be globally unique (hard todo; an approximation could be sufficient)
- not dependent on host addresses
- should not depend on mac
- constant length
- cryptographically random
scott: an identifier which can be determined / looked up is a bad thing
scott: global identifier requirements are hard to accomplish

henning: there might be more than one identifier

Packet Format 

Henning: XML/ASN.1 out of scope (no candidate)
Variations of TLV:

External described:
RSVP: Type has two components (meaning and data type)

Internal described: 
Diameter for example

Working Group Update (John)

An application on middlebox communication should be added to the working group
(will be added to the charter)

Requirements: good comments have been submitted / incorporate them and resubmit them to the mailing list 

Henning: the requirements do not reflex midcom specific issues

John: My understanding of the requirements draft is help the working group to develop a common language. do not require every possible use. get the requirements draft done - not useful to discuss them too long. henning is requested to review them. 

scott: should be real requirements and not desire (less is more)
john: example aaa - many of the required features might not be deployed in future
if a requirement is not in the draft then it does not mean that a solution is not fullfilling 

nsis threats should go to last call soon
framework is fairly stable 

henning: framework - requirements document inter-relationship (cross-referencing)
robert: framework document 

3 critical issues:
- layer split
- mobility issues
- off-path issues

3-6 month a possible target to make final comments

analysis document:

- what have we learned from the past.
- humm at the next ietf meeting to see if the analysis document is useful.
- john thinks there is a need to capture knowledge of what works and what not. 
- every working group has to re-investigate security issues (it would be good to have some documents to for example describe current cipher-recommondations)

henning: there are design tradeoff where you never get consensus on. hence it would be better to publish them as a technical report

NSIS Framework Issues (Robert)

Clarification about what the term ntlp means. 
inter-layer api?
try to include functions which immediately interact with lower layers

NTLP issues

is there agreement that the ntlp only carries something between two nsis peers?

ntlp has
- to provide discovery
- to interact with routing

upstream/downstream direction:
- ntlp to decide where go
- nslp to trigger it (semantics) 

henning: option
- ntlp as a forwarder
- bypass functionality

henning: it is hard to detect a route change in a non-nsis node
a route change is detected downstream -> the upstream can be detected downstream and a message can be transmitted upstream. to provide this functionality nslp functionality can be used. 

is reverse routing required by all nslps?
- ni does not care that the operation succeeded/ no message back 
- message from the other end could be transmitted back to the ni.

henning: a number problems with that! (security, transport)

assumption: the infrastructure for reverse routing has to be established
if only discovers downstream peers, but must be capable of forwarding message upstream

two basic options for ntlp functionality: Single-hop vs. multi-hop

Single-hop: this would allow an nsis message only be transmitted between two nsis peers

Multi-hop: should it be possible to transmit an empty nslp message over multiple nsis nodes? if so then the ntlp must have more functionality

relationship between middlebox and qos state (for a single session identifier): keep them separate: no strongly coupling between qos and  firewall/nat state - but it should be further discussed on the mailing list. 

john: learning from sip is a good thing. a tcp based sip stack is much nicer to work with/implement
henning: state machine got complex due to additional support of udp and because 
* semantics of message reception
* message reception
two state machines required

this is only about performance and not about semantics of various messages

scott: multi-stream / hol

scott: congestion control (hop-by-hop or end-to-end)
van jacobson: link-per-link congestion control is not a good thing
henning: congestion control: has to be hop-by-hop
end-to-end is not as possible in the nsis case
henning: flow control at each node and loss less buffering

flow control is the most important property
keeping the edge under network overload conditions in a save state

if we want to have these options (or ever use an existing transport protocol) then we cannot go with end-to-end addressing
john: we cannot decide now which are mandatory/optional

flow identifiers

which information should be included at the ntlp?
the flow identifiers can be arbitrary complex
(just enough to get it through nats)

should wildcarding be allowed. would nats allow this? there was some discussion at the midcom list. 

ruediger: an ntlp protocol to itself use a midcom protocol to request a nat binding to subsequently allow the qos signaling protocol go through

henning: holding type of nat state information. hence some solution might not work everywhere. 
robert: how much an we do for nats. what is the simplest way to provide this functionality.

henning: can we do anything? we need at least the 5 tuple. the nat box might not be able to keep the binding to long. it is not only about the address re-writing. it is also about requesting a binding lifetime to adjust the binding lifetime

henning: do you allow more than on?
wildcarding issue:
- efficiency (you could transmit more than one message)
- transactional semantics (all or none of them) acit semantics 

can nslps update objects in ntlp?

scott: we cannot put any constraints to it. 

state management

should the ntlp provide a managment service?

scott: lower latter would create the state installation and management

henning: there is two kind of state 
- not transport management type of state
- signaling state information

henning: it does not to be part of the protocol specification. where to locate state is part of the implementation

henning: some state identifier + timer + nslp state which gets logically removed 
timer value can be a configured value (specification) or as part of the signaling application

it would be good to describe advantages / disadvantages

john: connection & soft-state is a fuzzy concept

a tcp connection does not need to be related to an NSIS session (one tcp connection might be associated to more than one nsis session instance)
should the ntlp the upper layer nslp that a transport layer connection broke done (might be - api or performance issue)

agreement: ntlp failure does not delete nslp state

john: keep things separate / let the end systems decide / do not combine two different 
example: nat and qos signaling
first signaling nat and later signal qos signaling

cedric: this might be expensive

some favor to keep the state information at the nslp

robert: request to provide input on a state management service

Scoping

scott: it cannot be done. there is an endless discussion about this issue on the ipv6 mailing list

if people have well-defined chunks then it should be provided at the nslp. 
local objects are also a scoping issues

Rerouting / Mobility events

- how to detect it 
- how to handle them (who can handle merging/deletion to avoid double booking)
- is this signaling application specific?

Will be discussed tomorrow

Security issues

should security between non-adjacent nodes be provided? 

NSLP                            NSLP          NSLP
NTLP         NTLP         NTLP         NTLP

scott: if the NSIS protocol chooses tcp then it must provide some protection
we don't want add new dos attacks
dos attacks come in various flavors
types of dos attacks and the issues with it should be addressed within the nsis threats document

scott: there are some environments where tcp/sctp might not be the right answer (wireless links)

heavy discussion about transport protocols
henning: we need to decide which properties we would like achieve

robert: would the end-to-end nsis protocol break if a protocol is used between two peers which does not provide a certain property?

robert: mandate requirement at the transport layer
henning: what do you achieve if one hop does not provide reliability in the middle in the network?
henning: the danger is then that people add some functionality for end-to-end layer

georgios: even bob braden specified a raw ip and a tcp type of transport

henning: there are two issues (i am concerned about (b))
a) we do not need certain properties
b) we want to implement at the nslp

scott: dealing with the single link as a special case - hence in a certain environment it might be ok to provide restricted functionality

ACTION: from john to robert: send a mail (what is the current thinking what is needed). anyone should reply with a reason.

scott: is also concerned with tcp in a hop-by-hop environment

Using RSVPv1 as NTLP suggestions for modifications on RFC2205 (Georgios)

ntlp functionality:
- any node should be able to asynchronously generate a signaling message
- load sharing capability
- softstate
- local object
- support for non nsis aware routers along the path

some ntlp should be stateless (skipping the intermediate nodes) - optional / performance enhancement (only used within the admin domain)

henning: do you worry about reliability?
georgios: no - not discussed

robert: couldn't you simply say that you support udp?

scott: we shouldn't rule out a proposals

john: provide additional motivations why it is a good way forward
scott: why isn't it a good way forward

NTLP Design Considerations (Robert)

How does an NTLP entity detect that it is the last one before data receiver?
this issue is caused by the following two reasons:
- new application support (midcom)
- one of the endpoints does not support NSIS

Capability discovery: introduced by providing more generality 

A couple of re-route detection mechanisms.

robert: should nsis depend on stun to do the nat business?
scott: let us not do that!

do we optimize for low setup latency?

sven: it is more important to react on changes than a low setup latency

re-routing might be important for some applications (e.g. firewall/nat) - whereas for other applications such as QoS it does not matter too much

in RSVP a refresh is not handled with the same priority as the regular messages

failure management: timers 

conclusion: there are new problems introduced - these need to be addressed somehow
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis