The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Jun> msg00092



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

wg last call soft preemption question

  • From: Loa Andersson <loa@pi.se>
  • Date: Wed, 30 Jun 2004 15:01:08 +0200
  • User-Agent: Internet Messaging Program (IMP) 4.0-cvs
  • X-Originating-IP: 66.166.166.196


J-P,

I guess that this shows that some text is needed to clarify the
motivation section.

Something to the effect that placing the preempting LSP in such
a way that (some extra) overbooking is the case, might be used
to improve the possibilities to re-route the preempted LSP without
losing packets.

However, this is just improving the chances not "takin care of",
at least as long as the overbooking is such that we are dropping
packets.

/Loa



Hi Eric and Loa,

Comments in line,

At 06:59 PM 6/29/2004 -0400, Eric Gray wrote:

> Loa,
>
>         I guess that depends on whether you consider it is the traffic
> which has a higher priority or the setup request.  You can account for
> the fact that completing an in-progress transaction has a naturally
> higher priority that starting that same (or a similar) transaction by
> using setup and holding priority, but does anyone actually support the
> use of distinct setup and holding priority in both implementation and
> deployment?


Note sure whether your comment addresses Loa's point ...

See below,


> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Loa
> Andersson
> > Sent: Tuesday, June 29, 2004 6:19 PM
> > To: mpls@UU.NET
> > Subject: wg last call soft preemption question
> >
> > All,
> >
> > in the motiviation (section 2) for the
> > draft-ietf-mpls-soft-preemption-02.txt it
> > is stated that through the preemption as defined in rfc3209 traffic
> > on the "to be preempted LSP" is (unnecessarily) abruptly preempted.
> > The transit traffic is disregarded.
> > I guess this is true, but isn't the (the most common) case here that
> > the preemting LSP has a higher priority than the preemepted, and if
> > you withhold the preemption, waiting for the traffic on the preempted
> > LSP to be taken care of, you will waste traffic with higher priority
> > during that wait?


Well, we may indeed end up having some temporary overbooking situation (until
the soft preempted TE LSP is rerouted by its head-end) but:
1) The overbooking reservation does not necessarily mean traffic congestion
(this highly depends on the TE LSP sizing strategy)
2) This could be used in conjunction with Diffserv, should the traffic from the
higher priority TE LSP receive a better QoS

PS: the "Sof Preemption Desired" bit has been defined to provide the required
granularity.

Cheers

JP.

> >
> >
> > /Loa
> >
> > Loa Andersson
> > +46 739 81 21 64



/Loa

Loa Andersson
+46 739 81 21 64