Subject: RE: [NSIS] Re: Modularity and grouping QoS requirements

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 1 Mar 2002 11:20:23 +0100

Hi Cedric,

|one reason for using the model in draft-nsis rather than the one in
|draft-partain is that it allows to define mobility requirements.

I do not agree. In the draft-partain QoS requirements are derived from 
particular scenarios, one of them being the Mobile IP scenario and the
mobility requirements are part of the draft.
In the Mobile IP scenario this is already shown, when a handoff 
occurs the new reservation is needed from the NAR to the "Joint point 
of reservation" router that is located into the QoS aware segment that 
maintains an end to end reservation but due to handover it 
may change/modify this reservation.  

[NSIS] WG draft on the other hand on the mobility requirements refers
draft-ietf-mobileip-qos-requirements-01.txt.
If you compare the draft-partain and draft-ietf-mobileip-qos-requirements-02.txt.
you'll see that that these mobility requirements are in both drafts.

|For instance, think of a handoff, where the previous access 
|router (PAR)
|transfers QoS context to the new access router (NAR).
|There is no NAR-PAR interface in draft-partain; however, it is easy
|to see that the NAR is a QC (making the CAC decision at least) for
|the new path, and PAR a QI.
Note that in draft-partain the Access Routers are denoted as Border Node, 
so one of the QoS context transfer requirements that will apply to an 
interface similar to your the NAR-PAR is given in 
Section 5.2.2, draft-partain.
However, this is not explained in detail how it would be done. Probably
there may be more issues related to the interworking with QoS context
transfer protocols defined in SEAMOBY.
Do you already see any other requirements on such interface?

|Another drawback of the 'interface' framework is that QoS signaling is
|not necessary limited to interfaces. For instance, to update some 
|reservation
|after a handoff, you'd need to signal to the crossover router(s), 
|wherever it
|is. Most likely this crossover router does not correspond to 
|any interface.
|Note that draft-nsis either does not provide such framework, 
|but it could
|easily (should) be added with a QoS Termination point 
|abstraction. I think
|it is a dead end to assume the starting point and the end point of the 
|QoS signaling to
|be some pre-defined interface. Draft-nsis goes a half step in the right
|direction by allowing the starting point to be anywhere and 
|abstracting 
|it into
|the QI, which is a better starting point.
The purpose of grouping the requirements according to different 
interfaces where they apply to is not to limit the starting and ending
point of the protocol. The purpose is to see which requirements apply
to different parts of the network in the end-to-end path. We all agree
that what is needed in the access is not the same as what is needed 
in the core, which means that we need to identify these requirements for
a protocol that we would like to use end-to-end. The only way to achieve 
this is by supporting modularity in the protocol.
Further draft-partain does not restrict the starting point of the
protocol either.
The major problem in the [NSIS] WG draft is that the requirements are
deined for the abstract entities QI/QC and if there is no idea on where
in the network this requirements apply it is going to be difficult to 
design an NSIS protocol fulfilling these requirements.

Regards,
Vlora

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

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 01 Mar 2002 10:29:13 -0800

Vlora,

>may change/modify this reservation.  
there is no such interface however. Maybe your document should be made 
clearer as to
how the 'interface approach' solves this.

>you'll see that that these mobility requirements are in both drafts.
I do think the framework of the [NSIS] requirements should allow the 
phrasing of

draft-ietf-mobileip-qos-requirements-02.txt's requirement with
[NSIS] terminology.

>Section 5.2.2, draft-partain.
Mmmmh, it is bit of a stretch to say that 5.2.2 covers this. I don't see 
how sending a 'congestion
notification' addresses setting up QoS on the new path.

>
>However, this is not explained in detail how it would be done.
>
> Probably
I am not discussing requirements yet, just their framework.

>point of the protocol. 
but that's what it does in practice.

>The purpose is to see which requirements apply
>a protocol that we would like to use end-to-end. 
>
end-to-end is not the only use of the protocol, I am sure you did not 
mean this.

>The only way to achieve 
This is a different point: I agree that supporting modularity in the 
protocol is a goal here.
I disagree that the 'interface signaling' approach is the 'only way' to 
achieve modularity.

>Further draft-partain does not restrict the starting point of the
The use-case scenario is good for each single one of the described case. 
So you can draw n diagrams for n situations, and say, in these n cases, 
QoS is initiated here. But comes case (n+1),
and you have to go back to the drawing table. It does not restrict 
starting point in this sense,
but the framework is not scalable. In my view, a scalable framework (in 
the order of the scenarios)
is the best way to get to a scalable protocol.

>design an NSIS protocol fulfilling these requirements.
The major problem the other way round is that if you define explicitely 
QI/QC for every n cases you
can come up with, you won't address the n+1 case when it arises. So 
combining both approaches
somewhere in the middle should be the objective. The [NSIS] WG is as 
good a starting point as
any.

Cedric.