Subject: RE: [NSIS] Can we do without Q-spec stacking?

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Sun, 19 Mar 2006 21:39:21 +0100

Hi Robert,

We have discussed this issue earlier. Stacking increases the flexibility of NSIS, for example to support heterogenios networks using different QoS models. In addition, it reduces the no. of required sign. messages considerably in some cases. As a consensus, we have limited the number of possible QSpec to 2. So I am not in favor to remove this feature.

Best regards, Attila

> -----Original Message-----
> From: Robert Hancock [mailto:[email-masked]]
> Sent: Sunday, March 19, 2006 4:43 PM
> To: [email-masked]
> Subject: [NSIS] Can we do without Q-spec stacking?
> 
> 
> Hi,
> 
> I reviewed the QoS-NSLP on the flight yesterday and the above
> question occurred to me about half-way across. 
> 
> We introduced stacking [see below for historical background] as
> a means for accommodating localisation of the QoS specification
> within particular domains. I think that's still a legitimate 
> goal. However, the specification now has another way to achieve
> the same thing, namely by creating a local signalling session
> and using the BOUND_SESSION_ID to correlate the two at the edges,
> with the e2e session ignored in the interior. 
> 
> I don't think it would take much work to eliminate the concept from
> the qos-nslp (I haven't checked the qspec yet). And I'm sure there
> would be tears of joy in some quarters.
> 
> r.
> 
> Background:
> For a trip down memory lane, check out section 4.4 of
> http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt
> (from 2002...). At the time, the main advantage of the stacking
> approach was that domain boundary nodes could do all their processing
> on a single message rather than having to correlate messages of 
> multiple sessions. However, it now turns out that we can't avoid
> that type of complexity for other reasons, including
> - any sort of aggregation (where you have to handle 1+N messages)
> - where the interior session needs uses different GIST transport
>   characteristics (RMD)
> - where it is natural to hide the e2e session in the interior
>   (tunnel e.g. for mobility/vpn scenarios)
> Given that session correlation is needed in all these other cases,
> the advantage of being able to do without it in a particular case
> basically vanishes. It's probably simpler to use a single mechanism
> to handle everything.
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Sun, 19 Mar 2006 20:51:20 +0100

Hi Robert,

Best regards, Attila

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Thu, 23 Mar 2006 17:35:01 +0100

Hi Robert,

I also think that stacking is a useful function. 

As an example, In RMD QoS model, we use stacking two QSPECs in Response messages, since both QSPECs are delivered reliably edge-to-edge. We use two Reserve messages (edge-to-edge and end-to-end) bounded together but with a very good reason: namely intra-domain Reserve requires datagram transport, whereas the other one reliable transport.

The workaround of stacking is using two parallel messages with two different QSPECs. I.e. it complicates the signaling schemes. My other major concern is that sending bounded messages instead of stacking may negatively influences the protocol performance. Bounded messages may slow down the system if some of these messages are lost or delayed for some reason. 

Best regards, Attila

> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: Monday, March 20, 2006 2:50 PM
> To: Robert Hancock
> Cc: [email-masked]
> Subject: RE: [NSIS] Can we do without Q-spec stacking?
> 
> 
> 
> Hi,
> 
> So, your idea is that since one anyway implements session binding and
> tunneling, then stacking comes along "free". What if one 
> doesn't implement
> the binding and aggregation at all in his routers because the 
> domain only
> needs the simple stacking functionality, i.e., use a 
> different QOSM within 
> the domain?
> 
> Jukka
> 
> On Mon, 20 Mar 2006, Robert Hancock wrote:
> 
> > jukka,
> > 
> > > Hi Rob,
> > > 
> > > I really don't see how life would be so much more fun with a 
> > > single QSPEC
> > > allowed. The stacking of two QSPECs is a good idea, quite 
> simple to
> > > implement the processing for it, and has shown to have 
> > > support for a long
> > > time. To support the stacking through implementing a separate
> > > domain-internal session concept, and the processing for 
> it would be a
> > > number of times more complex and time consuming.
> > 
> > how is it more complex than what the draft already states or implies
> > is needed for aggregation and tunnel operation (and all the other
> > session binding scenarios)?
> > 
> > > If one wants to implement
> > > the same functionality to stacking through a separate 
> > > session, he is free to do so.
> > 
> > what I am questioning is that it seems we could have a choice 
> > between:
> > a) implement something complex for cases A-Y and simple for case Z
> > b) implement something complex for cases A-Z
> > Which of (a) or (b) leads to a simpler protocol?
> > 
> > r.
> > 
> > (leaving aside of course the question of whether stacking is really
> > simple, on which other people have much stronger views than me.)
> > 
> > > 
> > > Jukka
> > > 
> > > On Sun, 19 Mar 2006, Robert Hancock wrote:
> > > 
> > > > Hi,
> > > >