Subject: [NSIS] QSPEC: Pre-emption

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 24 Mar 2007 20:36:04 +0200 (EET)

We (at least Roland, Andrew, Georgios) have thought a bit more about the 
pre-emption, and how&where it should be described. Basically, it is a 
"problem" of QOSMs. The NSLP provides certain messages to inform of 
pre-emption, and who caused it (my recent proposal on the mailing list).

But, how does a QNE choose a flow to be pre-empted in the first place is 
out of scope of the NSLP. Yet, it might be good to say a few words about 
how to choose the "right" flow to pre-empt to help QOSM designers.

One simple idea we have talked about is that the QNE should try to choose 
a low(er) priority flow where the MRI is "close" (esp. the target IP) to 
the higher priority flow. This has the benefit that the pre-empted flow 
may share most of the path with the high priority flow. If the pre-empted 
flow has a random MRI, in case of heavy congestion, QNEs downstream may 
not see the same low(er) priority flow, and, thus, pre-empt other flows. 
Thus, in order to accommodate one high priority flow, the network may be 
killing N other flows.

Do you think giving advise on pre-emption to QOSM designers is out of 
scope of the QSPEC Template?

Cheers,
Jukka

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Mar 2007 14:14:37 +0100

hi,

a very simple answer: 

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: 24 March 2007 18:36
> To: NSIS Working Group
> Subject: [NSIS] QSPEC: Pre-emption
> 
> 
> We (at least Roland, Andrew, Georgios) have thought a bit 
> more about the pre-emption, and how&where it should be 
> described. Basically, it is a "problem" of QOSMs. The NSLP 
> provides certain messages to inform of pre-emption, and who 
> caused it (my recent proposal on the mailing list).
> 
> But, how does a QNE choose a flow to be pre-empted in the 
> first place is out of scope of the NSLP. Yet, it might be 
> good to say a few words about how to choose the "right" flow 
> to pre-empt to help QOSM designers.
> 
> One simple idea we have talked about is that the QNE should 
> try to choose a low(er) priority flow where the MRI is 
> "close" (esp. the target IP) to the higher priority flow. 
> This has the benefit that the pre-empted flow may share most 
> of the path with the high priority flow. If the pre-empted 
> flow has a random MRI, in case of heavy congestion, QNEs 
> downstream may not see the same low(er) priority flow, and, 
> thus, pre-empt other flows. 
> Thus, in order to accommodate one high priority flow, the 
> network may be killing N other flows.
> 
> Do you think giving advise on pre-emption to QOSM designers 
> is out of scope of the QSPEC Template?

basically I would say no. At least any normative text will hit
endless debates about regulation and lawfulness. At most one
could point out the consequences of particular strategies, but
it would be preferable IMHO to refer to other documents.
(In other words, I assume that anything useful that can be
written on this topic in the IETF has already been written.)

robert h.

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Mon, 26 Mar 2007 08:22:31 -0500

Jukka, All, 

> Sent: Saturday, March 24, 2007 2:36 PM
> To: NSIS Working Group
> more about the 
> first place is 
> try to choose 
> downstream may 

I agree with Robert, this is definitely out of scope for QSPEC.  Enough
is said already in the document and the RFC references provide the
sufficient details.  We are asking for endless debate if we try to plow
new ground here.

Thanks,
Jerry

---

From: <[email-masked]>
Date: Mon, 26 Mar 2007 08:29:05 -0500

Hi Robert,

Without looking too closely into the details, I do think that refering
to the MLPP drafts in TSVWG would be good.  I know they caused a lot of
discussing in TSVWG, for example.

John 

>From: ext Hancock, Robert [mailto:[email-masked]] 
>Sent: 26 March, 2007 06:15
>To: Jukka MJ Manner; NSIS Working Group
>Subject: RE: [NSIS] QSPEC: Pre-emption
>
>hi,
>
>a very simple answer: 
>
>> We (at least Roland, Andrew, Georgios) have thought a bit more about 
>> the pre-emption, and how&where it should be described. Basically, it 
>> is a "problem" of QOSMs. The NSLP provides certain messages 
>to inform 
>> of pre-emption, and who caused it (my recent proposal on the mailing 
>> list).
>> 
>first place 
>> is out of scope of the NSLP. Yet, it might be good to say a 
>few words 
>> about how to choose the "right" flow to pre-empt to help QOSM 
>> designers.
>> 
>> One simple idea we have talked about is that the QNE should try to 
>> choose a low(er) priority flow where the MRI is "close" (esp. the 
>> target IP) to the higher priority flow.
>> This has the benefit that the pre-empted flow may share most of the 
>> path with the high priority flow. If the pre-empted flow has 
>a random 
>> MRI, in case of heavy congestion, QNEs downstream may not 
>see the same 
>> low(er) priority flow, and, thus, pre-empt other flows.

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 26 Mar 2007 16:55:33 +0300 (EEST)

Hi Rob,
Good point. Let's drop this item.

Jukka

---

From: David R Oran <[email-masked]>
Date: Mon, 26 Mar 2007 10:50:27 -0400

I'll note that what started this thread is in fact a protocol issue  
and not a local preemption algorithm issue. I was actually pointing  
this out to Jukka and some others in a hallway conversation and it  
stimulated them to do some thinking on the subject.

It turns out that purely local preemption algorithms interact quite  
badly under heavy load and cause considerable "collateral damage"  
whereby many more flows get preempted than the number required to  
recover the resources needed to admit the higher precedence flow.  
this can be particularly bad in a distaster management situation  
where many of the higher-precedence flows wind up not being fully  
established due to host overload or failures. We have observed this  
in real world deployments with RSVP.

Cisco has a proprietary (and IPR encumbered) technique to overcome  
this. It uses an RSVP extension. We have no plans to introduce this  
into the IETF. I suspect there are other approaches that would not  
infringe, but nevertheless I want to be on record that I am NOT  
suggesting that the NSIS go in a particular direction here and later  
discover it runs up against Cisco IPR. If this happens by accident, I  
will of course inform the WG of the possible overlap.

If you want a more detailed description of the failure scenarios,  
I'll be happy to go into more depth without discussing solutions. I  
think Jukka et. al. understood them quite well after our conversation  
though.

One last "shot across the bow". I believe this is yet one more  
example of why priority/preemption, along with some other  
abstractions, really ought to have been a separate "sub-layer" in  
NSIS between GIST and the various signaling applications. Why should  
NSLP, NAT-FW, and mobility all separately solve the state preemption  
problem? But you folks all know that's been my opinion for a very  
long time...

Cheers, Dave.

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 26 Mar 2007 21:11:51 +0300 (EEST)

Yes, I think I understood the concepts relatively well. The problem is 
after all quite challenging - would be a fun exercise to figure out new 
ways to perform pre-emption with minimized collateral damage.

In this respect, I was proposing to add certain rather simple mechanisms 
to the QoS NSLP to allow QoSM designers to built various pre-emption 
mechanisms.

I don't want to define any specific approach in the NSLP spec, just enable 
certain functionality, like telling the reason for a tear-down event. This 
should not infringe any Cisco IPR (I hope) - I'll leave it up to QoSM 
designers that would want to implement pre-emption to figure out the right 
way to use NSLP messages.

Thanks for the note, Dave.

Jukka

On Mon, 26 Mar 2007, David R Oran wrote:

> I'll note that what started this thread is in fact a protocol issue and not a
> local preemption algorithm issue. I was actually pointing this out to Jukka
> and some others in a hallway conversation and it stimulated them to do some
> thinking on the subject.
> 
> It turns out that purely local preemption algorithms interact quite badly
> under heavy load and cause considerable "collateral damage" whereby many more
> flows get preempted than the number required to recover the resources needed
> to admit the higher precedence flow. this can be particularly bad in a
> distaster management situation where many of the higher-precedence flows wind
> up not being fully established due to host overload or failures. We have
> observed this in real world deployments with RSVP.
> 
> Cisco has a proprietary (and IPR encumbered) technique to overcome this. It
> uses an RSVP extension. We have no plans to introduce this into the IETF. I
> suspect there are other approaches that would not infringe, but nevertheless
> I want to be on record that I am NOT suggesting that the NSIS go in a
> particular direction here and later discover it runs up against Cisco IPR. If
> this happens by accident, I will of course inform the WG of the possible
> overlap.
> 
> If you want a more detailed description of the failure scenarios, I'll be
> happy to go into more depth without discussing solutions. I think Jukka et.
> al. understood them quite well after our conversation though.
> 
> One last "shot across the bow". I believe this is yet one more example of why
> priority/preemption, along with some other abstractions, really ought to have
> been a separate "sub-layer" in NSIS between GIST and the various signaling
> applications. Why should NSLP, NAT-FW, and mobility all separately solve the
> state preemption problem? But you folks all know that's been my opinion for a
> very long time...
> 
> Cheers, Dave.
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 27 Mar 2007 10:26:30 +0200

Hi Jukka

I think that your proposal is a reasonable one!

Best Regards,
Georgios 

> Sent: maandag 26 maart 2007 20:12
> To: David R Oran
> Cc: NSIS Working Group; Hancock,Robert
> Subject: Re: [NSIS] QSPEC: Pre-emption
> 
> 
> Yes, I think I understood the concepts relatively well. The 
> problem is after all quite challenging - would be a fun 
> exercise to figure out new ways to perform pre-emption with 
> minimized collateral damage.
> 
> In this respect, I was proposing to add certain rather simple 
> mechanisms to the QoS NSLP to allow QoSM designers to built 
> various pre-emption mechanisms.
> 
> I don't want to define any specific approach in the NSLP 
> spec, just enable certain functionality, like telling the 
> reason for a tear-down event. This should not infringe any 
> Cisco IPR (I hope) - I'll leave it up to QoSM designers that 
> would want to implement pre-emption to figure out the right 
> > recover the resources needed to admit the higher precedence 
> flow. this 
> > can be particularly bad in a distaster management situation 
> where many 
> > of the higher-precedence flows wind up not being fully 
> established due 
> > to host overload or failures. We have observed this in real 
> world deployments with RSVP.
> > 
> > If you want a more detailed description of the failure 
> scenarios, I'll 
> > be happy to go into more depth without discussing 
> solutions. I think Jukka et.
> > One last "shot across the bow". I believe this is yet one 
> more example 
> > of why priority/preemption, along with some other 
> abstractions, really 
> > ought to have been a separate "sub-layer" in NSIS between 
> GIST and the 
> > various signaling applications. Why should NSLP, NAT-FW, 
> and mobility 
> > all separately solve the state preemption problem? But you 
> folks all 
> > know that's been my opinion for a very long time...
> > 
> > Cheers, Dave.
> > 
> > > >We (at least Roland, Andrew, Georgios) have thought a bit more 
> > > >about the pre-emption, and how&where it should be described. 
> > > >Basically, it is a "problem" of QOSMs. The NSLP provides certain 
> > > >messages to inform of pre-emption, and who caused it (my recent 
> > > >proposal on the mailing list).
> > > >
> > > >But, how does a QNE choose a flow to be pre-empted in the first 
> > > >place is out of scope of the NSLP. Yet, it might be good 
> to say a 
> > > >few words about how to choose the "right" flow to 
> pre-empt to help 
> > > >QOSM designers.
> > > >
> > > >path with the high priority flow. If the pre-empted flow has a 
> > > >random MRI, in case of heavy congestion, QNEs downstream may not 
> > > >see the same low(er) priority flow, and, thus, pre-empt other 
> > > >flows.
> > > >Thus, in order to accommodate one high priority flow, 
> the network 
> > > >may be killing N other flows.
> > > >
> > > >Do you think giving advise on pre-emption to QOSM 
> designers is out 
> > > >of scope of the QSPEC Template?
> > >
> > >endless debates about regulation and lawfulness. At most one could 
> > >point out the consequences of particular strategies, but 
> it would be 
> > >preferable IMHO to refer to other documents.
> written on 
> > >this topic in the IETF has already been written.)
> > >
> > >robert h.
> > >
> > > >
> > > >Cheers,
> > > >Jukka
> > > >