Re: draft-deoliveira-diff-te-preemption-01.txt - 2 comments.

[Jaudelice Cavalcante de Oliveira <jau@ece.gatech.edu>]

Hello Matthew,

Thanks for your comments. See below.

As you pointed out, the draft -01 is now available at:

http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te-preemption-01.txt


> Very interesting.
>
> 1)Possible spellings: analyzed (US) or analysed (British), but not
> analized.
> accommodate not accomodate ; achieved not acchieved ; successfully not
> succesfully.

Sorry for those... Sometimes the fact that Portuguese and English words
have similar spelling makes me confuse them...

> 2) I have a comment regarding the heuristics. I may be in over my head
> with this comment, but here goes. Summary: It seems to me that the
> heuristic will inadvertently prioritize high-bandwidth traffic over
> low-bandwidth traffic. The draft states that "gamma (b(l)-r)^2 penalizes
> a choice of an LSP to be preempted that would result in high bandwidth
> wastage."

r is the bandwidth needed to setup the high-priority LSP. The requested
bandwidth.

b(l) is the bandwidth of preemptable LSP l.

(b(l)-r)^2 will give LSPs with bandwidth closer to "r" a smaller "cost".
So if "r" is large, say 100, LSPs with bandwidth closer to 100 will be
preferred. If "r" is small, say 2, LSPs with bandwidth closer to 2 will be
preferred. So, the heuristic does not necessarily prefers low bandwidth
candidate LSPs.

> This necessarily implies that low-bandwidth LSPs are more vulnerable to
> being preempted than high-bandwidth LSPs of otherwise equal priority.
> This strikes me as not sensible*.

As explained above, the heuristic does not necessarily prefer low
bandwidth LSPs but rather the ones whose bandwidth is closer to the
requested value "r".

> Beta would tend to counteract this bias, but I can foresee where it
> would often be ineffective, e.g. where a low-bandwidth LSP or a
> high-bandwidth LSP could be preempted to make room for a high priority
> low-bandwidth LSP.  Beta is a constant (=1), and the low-bandwidth LSP
> will be preempted (bad).

I am not sure I understood your concern in the example above. Beta
minimizes the number of LSPs selected for preemption. If priority and
bandwidth are also taken into account, the heuristic will try to find a
small number of LSPs with low priority and bandwidth close to the
requested value "r".

>  In your first example, would an l17(b,p,y = 300,6,2) not be preempted,
> even using 'balanced' coefficients alpha=1, beta=1 and gamma=0.01?

l17 would be preferred from preemption if the bandwidth request for the
high-priority LSP is close to 300.

> In a state of bandwidth shortage, mabye it makes more sense not to weigh
> bandwidth wastage at all.  It seems to me that the gamma component
> should be eliminated.

The gamma component was included in order to control the preempted
bandwidth. E.g. Preempting LSPs that have bandwidth much larger that the
required one (r) might result in a high probability of not finding an
alternative route for such large preempted LSP (the rejected rate would
increase).

> I've continued reading and I see that this is the PN policy of 6.2.2. I
> would argue that PN is better than PB. The wasted bandwidth of this
> static moment in time should not be considered in evaluating the
> policies. (Really, it's not 'wasted' at all; it's being 'virtually
> reserved' (if I may call it that) for low-bandwidth LSPs, which, since
> we're in a state of bandwidth shortage, are likely to appear shortly.)

I believe the preference of PN over PB depends on the provider's interest.
I do agree that the extra bandwidth preempted could be used in the future,
but again it could become hard to reroute large LSPs.

> *E.g. a dozen users communicating using low-bandwidth communication,
> (e.g. something text based such as email or chat) should be rewarded
> over a pair of bandwidth hogs using videoconferencing.

I agree as long as the requested bandwidth is similar to the
videoconferencing, otherwise it could happen that an alternative path is
not available for such large LSP.

Cheers,

Jaudelice.