Subject: [NSIS] Minutes from Wednesday

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

NSIS interim meeting (Wednesday February 12) 

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:

Mobility Interaction (Hannes)

Short presentation on the generic limitations of mobility due to the selection of a flow identifier (if the flow identifier is a 5-tuple including the source ip address then a full packet classifier/flow identifier update along the entire path is required).

The session identifier provides some advantages to mobility. Interaction (api, triggers) from the mobility signaling protocol provides performance improvements and is comparable to route detection mechanisms.

Henning: from a protocol design perspective we should support something but an implementation should have the choice to delete something. there are some subtle race condition issues which could cause problems to the entire path

John: a teardown message for the old path might cause some problems - it is a performance improvement
Scott: no symmetric paths can be assumed (if there is more than a single isp along the path then it is very likely that there is no symmetric path anymore). 

henning: mobility is likely to introduce significant difficulties. 
john: mobility is left for further optimization (not target for the first work)

[marcus] what is the expected time range for a detected path change?
[hannes] depends on: refresh interval, route detection mechanism, interaction with mobility protocol, internal nsis protocol mechanisms (e.g. initiator triggered path detection mechanisms) etc.
[gk] 802.11 (100 feet), doesn't take long to drive 100 feet
[jl] is it 'need to remove state'?
[geib] have to link both reservations
[hannes] one of the observations of rsvp mobileip interaction is the importance of separation of flow identification and session identification
[hs] not only efficiency but mid-session failure for no reason (if you fail 
to release resources)
- downlink reservation
* protocol interaction is similar to a route change
[gk] main point: nsis should not discover cross-over router or MAP
[hannes] the discovery of the cross-over router is automatically provided due to existing of the session identifier
[reh] other work suggest you can do it by having a good implementation of 
mobility protocol and nsis protocol. could benefit from analysis what type 
of messages you send when. but don't think it covers all the cases.
[geib] do all potential anchor points have to be nsis-aware?
[hannes] no. 
[marcus] but completely different timing issue: route change is longer 
timeframe
[hs] don't care how frequently it happens but rather rapid transition from 
old one to new one. cleanup is probably more important for mobility.
[jl] implementation issue?
[hs] issue of old/new path: danger to tear down everything, because 
determining the cross-over point is difficult because of race conditions.
[jl] prefer to have it informative. some may want to let the state time out.
[hs] thought agreement this was an optimization. need to provide it but not 
mandate the use of it.
[jl] may be some situation where resource reservation is not as 'reserved' 
(more advisory than contractual)
[kwok] interdependence between upstream/downstream
[reh] seem to be different, may be dangerous to let one depend on the other.
[kwok] but what about correlation
[sob] will be difficult in the middle of the network
[hs] having coupling between both directions in the network is left for 
future work

Wireless and mobility support issues (Georgios)

Generic handover performance requirements

georgios: handover requests could be treated by higher priority
henning: by what? you only need to detect what is new and what is already existing - a policy issue.

minimize number of bits transmitted 

Implications using TCP over 2.5 and 3G wireless networks

characteristics of  2..5 and 3g wireless networks

john: this topic is outside the scope of nsis
henning: it effects all transport protocols
john: slow start is a problem
scott: an rfc which addresses this problem will pop-up soon

henning: wireless links affect the performance of protocols using retransmission (it is not a tcp specific problem)
if one can do better than tcp then we should present it. 

john: large number of small tcp session might cause problems. we should try to make sure that we avoid 
robert: reusing a transport layer connection for a number of message is an option
henning: re-implementing a tcp mechanism within ntlp does not solve the problem. 

markus: what of the functions do we need?
john: what are the transport things we need? georgios should provide some of the issues 

ietf pilc have studied the impacts and suggest:
- sacks
- tcp timestampe
- roc

Anticipated Handovers (Joachim Hillebrand)

reserving resources in advance
relationship to seamoby
scott: requires movement prediction

john: what in nsis can be done to enable this?
robert: there is a framework issue on this  - dependencies are not know

john: joachim should investigate to determine what are the requirements for nsis

henning: a generic mechanism would be good
john: it is currently premature to be done
scott: it is premature to add it to the charter. 
john: our work should be mobility be friendly
scott: but it does not require anticipation of the future
scott: there are surely a number of tricky things if there are more than one possible move

NSIS and Mobility - Layer Split & Framework Issues (Robert)

Some issues are open from the framework issues

Is mobility different to re-routing?

reservation theft:
- now system assumes some sort of "return-routability"

home address packet classifier is not feasible
reservation theft is easier

you have to have end-to-end signaling to update the packet classifier

repair is local - there is no option to localize a 

possible saving: for the unchanged path you should avoid aaa/policy control

you have to execute the signaling message exchange again
partial nslp execution? 

I ->  -> ->  -> ->  -> ->  -> R
                         \-> 
                              \-> ->    R 

What about the reverse direction?

What about a change in the middle of the middle network?
I ->  -> ->  -> ->  -> ->  -> R
             \->        -/
              \-> - ->/   

What about a tear-down? 

There are some dependencies with aaa/charging and mobility?

Should we support this?
G: for a small change we should 
Sven: delegation might be an option

unchanged path requires a packet classifier update

Should we support se-like reservations?
selective wildcard - comes with the possibility of multicast

sven: 
- se can only be used between the same points / used in conference type of applications
- 

combining different packet classifiers -> merge classifiers and qos 
henning: merging on prefixes (this already needs to be done for routing anyway); are routers more flexibility?

detecting crossover routers

- previous / next peer has changed
- are there other issues?

henning: 
- session identifier is necessary
- this identifier is sufficient to associate the existing state with an incoming message 
- move forward

henning: properties:
- constant over session
- globally unique

ACTION: session identifier was agreed 

was is used for?
- detect crossover router
- session ownership problem?

henning: options
- session identifier no security relevant (identity of the owner independent from the id)
- session identifier is security relevant 
- session identity (pk-based id)

- globally unique, random collision probably is small, not protected
- nobody can snoop is id (only participating nodes) 
- source authentication (authentication, pbk)

markus: decouple security and identifier 
henning: done combine too many things with the same mechanism
john: decouple ownership issue + write it down 
robert: we have a clear need for it.

henning: move forward - no one came up with a  
john: state in the document - it cannot be used as a ownership proposal
john: overloading the id is a bad idea as henning used

ACTION: currently cryptographically random id (not protected - no ownership)

CT/CARD issues

ACTION: john - keep it open 
action item for john to look at 5.3.5 of the framework and to comment on it. 

cedric: session id for group of flows and different nslp
henning: no; separate issues (a) flows (b) nslp

ad (b) we haven't made this decision yet. 

what is the semantically tying the two nslp instances (foo/bar) - what means the combination of foo and bar -> foo fails but bar is allowed etc. this gets very complicated and we don' t want to do it. 

john: this sounds like an optimization which should not be considered yet; this is not an ntlp discussion
 
ACTION: ad (a) it should not be done

henning: there are many things would like to add / keep the core spec small enough - otherwise it will never get implemented. 

we don't have to get them into the *-00 version.

john: we should not try to do 110 % - instead we do 90 % and then we have look at deployment/implementations. extensions can be added later. 
 
robert: the capability should be simple
 
cedric: Capability negotiation required?

henning: you have to provide something for the discovery. there are different type of issues:  there are some things that have mandatory, discoverable and optional parts. the optional parts can cause an error if not understood or blindly forwarded. every good protocol has this type of functionality.

henning: there is a danger: if there are two modes and you have a full fletched tp and you have a tp which provides nothing for specific links. bad: functionality implemented in two places (interactions get complicated)

if you do what rsvp refresh reduction did then every transport person would laugh us out of the room. it is not a solution - it is a hack.  

ruediger: there has to be something mandated - otherwise the interoperability is in danger!

john: what are the options?

NSIS Meeting Summary(John)

henning: milestones?

john: have been updated
henning: next due date?
john: requirements to IESG
nsis threats quite ready
meta-question for analysis doc

john: mobility stuff should be captured. possible rolled into the analysis document. 

henning: lessions are always in the eye of the beholder. 
john: we don't want to spend more time on the analysis document

sven: off-path signaling bof next time
(1 hour session)

john: describe why it is needed for a restricted environment. 
henning: 
a) people have a different notion of what off-path is? how you scope the problem. 
b) can be quite complicated

john: restricted to intra-domain signaling (inter-domain can always get very complicated)

sven: it might not only be a qos application
john: one or two good use-cases might be a good thing

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