Subject: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework)

From: Curtis Villamizar <[email-masked]>
Date: Thu, 24 May 2012 13:56:52 -0400

All,

Note the change in subject line.

In the discussion of the CL framework, a suggestion was made to change
the requirements.  Please comment on this suggestion.

The following would be added somewhere.

  Load balancing MAY be used during sustained low traffic periods to
  reduce the number of active component links for the purpose of power
  reduction.

I think the wording in the framework originally came from either Lucy
or Verizon (maybe Ning or Dave?).  Iftekhar is correct that it would
be best to mention this in the requirements if we are going to mention
it in the framework.

Curtis

btw- In each of these document we need to change Ning's affiliation.

In message <[email-masked]>
Iftekhar Hussain writes:
> > >
> > > > Please find below some comments on the 
> > > > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05.
> > >
> > >
> > > ----------------------------
> > >
> > > 2.1. Flow Identification
> > >
> > > "Operator may have other objectives such as ...composite link energy 
> > > saving, and etc. These new requirements are described in 
> > > [I-D.ietf-rtgwg-cl-requirement]"
> > >
> > > Comment:
> > >
> > > I don't recall any energy saving related requirement (or discussion) 
> > > in the [I-D.ietf-rtgwg-cl-requirement.  Suggest removing the text 
> > > "energy saving etc."
> >  
> > You are entirely correct that there are no energy savings mentioned in
> > the requirements document.  This wording came from one of the other
> > authors but I think I understand the intent.  There is a daily cycle
> > (and less so a weekly cycle) to traffic levels.  During the low
> > traffic hours (generally late at night for local hours of night)
> > traffic can be rebalanced to reduce the number of active component
> > links.  Where it is possible to depower interfaces, this could result
> > in energy savings.
> >  
> > I'm OK with removing this example, though it is a very good example
> > and an goal that we should be pursuing.  Another option is to add a
> > "MAY" in the requirements docuemt somewhere that indicates that "Load
> > balancing MAY be used during sustained low traffic periods to reduce
> > the number of active component links for the purpose of power
> > reduction".
> >  
> [Iftekhar] OK. The latter option seems reasonable. 
> >  
> > I'll wait for further comments on this before making a suggestion on
> > how we will proceed.

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 May 2012 18:40:41 +0000

Agree on the suggestion. However, the text to be considered as following:

  Load distribution constraint MAY be used during sustained low traffic periods to
  reduce the number of active component links for the purpose of power
  reduction.

Lucy
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Thursday, May 24, 2012 12:57 PM
To: Iftekhar Hussain
Cc: [email-masked]
Subject: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework)

All,

Curtis

> > I'll wait for further comments on this before making a suggestion on
_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 24 May 2012 12:19:27 -0700

On May 24, 2012, at 11:40 , Lucy yong wrote:

> However, the text to be considered as following:
> 

I'd phrase that as "Constrained load balancing MAY ...".  I prefer balancing to distribution.

In any case, you'd want to add something to the effect that "normal" load distribution SHOULD be resumed when traffic increases, with flows being affected (again).

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 24 May 2012 15:56:04 -0400

In message <[email-masked]>
 
> balancing to distribution.

Duh.  Yeah.  Not sure how I managed to mangle the wording so badly and
not notice it so far.  I think this is best:

  Load distribution MAY be used during sustained low traffic periods
  to reduce the number of active component links for the purpose of
  power reduction.

The word "constraint" is dropped.

> In any case, you'd want to add something to the effect that "normal"
> load distribution SHOULD be resumed when traffic increases, with flows
> being affected (again).
>  
> Kireeti.

I see your point except that I don't see this as quite a big a
deviation from "normal" load balancing.

For example, if there are N components, then one could configure the
CL to shut off a component if a condition is met.  One such condition
would be the utilization of the composite would remain under some
configured percentage if traffic remained at the same levels as was
recorded over a prior interval.  For example, if M components remain
(where 1 < M <= N) and traffic was measured in 100 msec intervals for
20 minutes with no interval exceeding a level where M-1 components
would be loaded over 80%, then the number of components is reduced by
one and measurement starts over.  If the composite is ever loaded over
80%, then a component is added back.

That was just an example.  The requirements would just indicate that
some unspecified technique MAY be used to address the requirement.
The framework might put a few more constraints on the technique, but
only if we think that would be needed.  Since coordination on both
sides would be needed to power down components, a protocol extension
would be needed ... eventually, if we could ever get past requirements
and framework.  A bit like LACP only not for Ethernet component links
only, or like Avici Composite Link (abandonned trademark) only not
just for component links using PPP (like POS).

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 24 May 2012 11:31:48 -0700

>  reduce the number of active component links for the purpose of power

Is the intent:

   Load balancing MAY be _changed_ during sustained low traffic periods to
   reduce the number of active component links ...

?

If so, a warning ("this may result in some packets being reordered, and a change in delay and jitter of some flows") should probably be added.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 24 May 2012 14:18:08 -0700

Hi Curtis,

> deviation from "normal" load balancing.

Shouldn't have said "normal"; shutting off a component doesn't make it "abnormal".

> CL to shut off a component if a condition is met.

My point is simply, shutting off a component means changing the load balancing algorithm.  Depending on how that's done, either the set of flows on the component being shut off, or all flows, will be affected.

Resuming the use of a shut-off component similarly affects some (or all) flows.

An implementor may want to consider the trade-offs of saving power but affecting flows vs. not.

Kireeti.

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 May 2012 21:23:45 +0000

I do not concern much on this because during low traffic period, it is often the case that the number of flows inside of TE tunnel are reduced dramatically over the network than the case that a flow size change dramatically between high traffic period and low traffic period. If operator want to consolidate the traffic and shutdown some component links during low traffic period, it should not cause BIG impact but bring the cost reduction. Of cause, operator will need to manage the frequency of switching to minimize the impact.  

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Thursday, May 24, 2012 1:32 PM
To: [email-masked]
Cc: Iftekhar Hussain; [email-masked]
Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework)

Is the intent:

?

Kireeti.

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 May 2012 21:29:30 +0000

Snip..

My point is simply, shutting off a component means changing the load balancing algorithm.  Depending on how that's done, either the set of flows on the component being shut off, or all flows, will be affected.
[[LY]] This depends how the load balancing is implemented. It is not necessary to impact all the flows. The set of flows on the component being shut off have to be moved to other components for sure.

Resuming the use of a shut-off component similarly affects some (or all) flows.
[[LY]] Again, this may not be true, depending on the implementation.

[[LY]] absolutely.

Lucy

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 24 May 2012 17:33:25 -0400

In message <[email-masked]>
Kireeti Kompella writes:
 
>    Load balancing MAY be _changed_ during sustained low traffic
>    periods to reduce the number of active component links ...
>  
> ?
>  
> If so, a warning ("this may result in some packets being reordered,
> and a change in delay and jitter of some flows") should probably be
> added.
>  
> Kireeti.

Kireeti,

You are correct that any change would be minimally disruptive.  In the
example I gave there could be no more than one change in 20 minutes,
but still more than zero.

I personally don't think a warning is needed here, but if you and/or
others feel it is needed I have no objections to adding it.  The text
would then be:

  [FR#N]   Load balancing MAY be used during sustained low traffic
           periods to reduce the number of active component links for
           the purpose of power reduction.

  As with any load balancing change, a change initiated for the
  purpose of power reduction may be minimally disruptive.  Typically
  the disruption is limited to a change in delay characteristics and
  the potential for a very brief period with traffic reordering.  The
  network operator when configuring a network for power reduction
  should weight the benefit of power reduction against the
  disadvantage of a minimal disruption.

The first paragraph is a requirement.  The second paragraph is
discussion and should not appear within a numbered list of
requirements.

I would like comments from you and others.  Do we need to add this
requirement?  If so do we need to add this warning?

Curtis

---

From: Iftekhar Hussain <[email-masked]>
Date: Thu, 24 May 2012 21:47:11 +0000

Curtis,

I also think, it would be a good idea to indicate the consequences of such load balancing change (if this event is going to cause service disruption).  FR#4 and FR#12 might be relevant.

Regards,
Iftekhar
-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 2:33 PM
To: Kireeti Kompella
Cc: [email-masked]; Iftekhar Hussain; [email-masked]
Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework)

Kireeti Kompella writes:
 
> > In the discussion of the CL framework, a suggestion was made to 
> > change the requirements.  Please comment on this suggestion.
> > 

Kireeti,

You are correct that any change would be minimally disruptive.  In the example I gave there could be no more than one change in 20 minutes, but still more than zero.

I personally don't think a warning is needed here, but if you and/or others feel it is needed I have no objections to adding it.  The text would then be:

The first paragraph is a requirement.  The second paragraph is discussion and should not appear within a numbered list of requirements.

I would like comments from you and others.  Do we need to add this requirement?  If so do we need to add this warning?

Curtis

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 May 2012 21:50:43 +0000

My preference is to add this requirement in the req. draft and add the warning in the framework draft when describing load balancing. Load balancing algorithm needs consider minimum impact when lost a component link or component link addition. This can happen when a component link fails or adding a new component link. This is not just for shutting off component link for energy saving.

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Thursday, May 24, 2012 4:33 PM
To: Kireeti Kompella
Cc: [email-masked]; Iftekhar Hussain
Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework)

Kireeti,

Curtis