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

[Cedric Westphal <[e-mail]>]

Vlora,

Vlora Rexhepi (ELN) wrote:

>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.  
>
there is no such interface however. Maybe your document should be made 
clearer as to
how the 'interface approach' solves this.

>
>
>[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.
>
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.


>
>
>|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.
>
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
>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?
>
I am not discussing requirements yet, just their framework.

>
>
>
>|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. 
>
but that's what it does in practice.

>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. 
>
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 by supporting modularity in the protocol.
>
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
>protocol either.
>
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.

>
>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.
>
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.

>
>
>
>Regards,
>Vlora
>



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