Subject: Re: [PWE3] [mpls] ELI as a reserved label

From: John E Drake <[email-masked]>
Date: Wed, 4 Aug 2010 06:48:32 -0700

Lucy,

I think you are using the term 'large flow' to mean a large number of  
packets exchanged between a particular source & destination?

In the context of ECMP, I think the definition of 'flow' is the set of  
all packets whose packet header field values map to the same path  
through the network towards the packets' destinations.

Given this definition of 'flow', your definition of 'large flow' is  
basically irrelevant.  This is because what we are really interested  
in ensuring that over time the number of packets sent over a set of  
parallel paths is roughly the same, and the techniques of adaptive  
multipath can be used to accomplish this.

Thanks,

John

Sent from my iPhone

On Aug 3, 2010, at 5:34 PM, "Yong Lucy" <[email-masked]> wrote:

> Shane,
>
> I agree with you that ELI is hard in applying P2MP and did not think  
> it
> thoroughly in the meeting week.
>
> Because ELI is only used when there is no application label, it is  
> better to
> encode the large flow indication on EL.
>
> Regards,
> Lucy
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of
>> Shane Amante
>> Sent: Saturday, July 31, 2010 9:38 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [mpls] [PWE3] ELI as a reserved label
>>
>> Hi Curtis,
>>
>> I had some time to think about this some more on the plane ride  
>> home.  See
>> below.
>>
>> On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
>>> In message <[email-masked]>
>>> Shane Amante writes:
>>>>
>>>> Curtis,
>>>>
>>>> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:
>>>>> The Entropy Label Indicator (ELI) is called for in
>>>>> draft-kompella-mpls-entropy-label-01.txt
>>>>>
>>>>> After brief discussion with Stewart and with Kireeti and Lucy  
>>>>> Yong,
>>>>> there were three uses of ELI that would benefit from making the  
>>>>> ELI a
>>>>> reserved label.  It may be premature to make any such request  
>>>>> and the
>>>>> remaining reserved label number space is sparse, so this will be
>>>>> floated as a separate draft, and put on hold awaiting  
>>>>> advancement of
>>>>> the drafts that depend on it.
>>>>>
>>>>> The three benefits of making ELI a reserved label are in:
>>>>>
>>>>> 1.  Extending any use of entropy-label to P2MP (where there are
>>>>>    multiple egress and the possibility of each egress requiring a
>>>>>    separate entropy label value is problematic for the ingress).
>>>>>
>>>>> 2.  Extending any use of entropy-label to any arbitrary position  
>>>>> in
>>>>>    the label stack such that in an aggregation LSP with aggregates
>>>>>    both MPLS-TP and MPLS LSP, load split on the MPLS LSPs is
>>>>>    simplified and not impacted by limiting label stack depth for
>>>>>    the MPLS-TP LSPs.  This is when label stack hash is limited to
>>>>>    support MPLS-TP as proposed in
>>>>>    draft-villamizar-mpls-tp-multipath-00.txt .
>>>>
>>>> I agree there are benefits to a reserved label for the above two
>>>> applications.  Most importantly, a receiving node would have pretty
>>>> clearly semantics that what [immediately] follows a reserved ELI is
>>>> the entropy-label, regardless of where the ELI is in the MPLS label
>>>> stack and without needing to be in the signaling path to know  
>>>> what is
>>>> the ELI value.
>>>
>>> "Now don't be sad ... 'cause two out of three aint bad".  [meatloaf]
>>>
>>> Its good to hear that you consider these to be useful.
>>>
>>> Note that an ingress LSR still needs to determine that egress LSR
>>> understands ELI to do anything.  To support MPLS-TP in MPLS the
>>> ingress needs to veryify that all LSR on the path support MPLS in a
>>> way that provides a compliant path for a contained TP LSP, but  
>>> that is
>>> out of scope of this discussion.
>>
>> I need to revise my statements wrt entropy-labels and P2MP LSP's.   
>> After
>> thinking about this some more, I no longer believe it makes sense  
>> to use a
>> reserved ELI value for P2MP LSP's.  More specifically, for a given  
>> P2MP
>> LSP, all receivers /MUST/ agree to receive entropy labels, because it
>> would be silly to (for example) expect core LSR's to strip-off the  
>> ELI and
>> an entropy-label mid-flight toward receivers that don't understand  
>> (or,
>> can't receive) entropy-labels.  The ramifications of this are that  
>> if a
>> head-end detects any receivers of a P2MP LSP that can't receive  
>> entropy-
>> labels, then the head-end LER/LSR must either: a) re-signal the  
>> whole P2MP
>> LSP toward all receivers so that the head-end will not send any  
>> entropy-
>> labels at all on the P2MP LSP; or, b) signal 2 separate P2MP LSP's:  
>> one
>> for entropy-label capable receivers and a second for non-entropy- 
>> label
>> capable receivers.  I don't know that we want to mandate one of  
>> those two
>> behaviors over the other, because SP's may ma
>> ke separate choices depending on whether they want to avoid extra
>> replication in the network at the expense of not being able to do  
>> flow-
>> based load-balancing, i.e.: Option (a), or don't mind the extra
>> replication of (potentially) 2 parallel P2MP trees on the same  
>> links in
>> order to attain some amount of flow-based load-balancing of the P2MP
>> traffic.
>>
>> So, in summary, I no longer see that draft-kompella-mpls-entropy- 
>> label has
>> a requirement for reserved labels for either P2P or P2MP LSP's  
>> (scenario 1
>> in your original e-mail).  Furthermore, I still maintain that  
>> discussion
>> of LFC and use of the MPLS TC field for indication of large vs. small
>> flows is orthogonal to draft-kompella-mpls-entropy-label (scenario  
>> 3 in
>> your original e-mail).  I haven't read draft-villamizar-mpls-tp- 
>> multipath-
>> 00 (scenario 2 in your original e-mail) so I can't speak to whether  
>> or not
>> there is a requirement for a reserved label there.
>>
>> Anyway, perhaps this will save you some time in that you don't need  
>> to
>> write a whole new draft as you originally proposed and, instead,  
>> may only
>> need to look at modifying your original draft.  :-)
>>
>> On a separate note, we intend to update draft-kompella-mpls-entropy- 
>> label
>> shortly to cover P2MP LSP's (RSVP & mLDP), plus add details  
>> surrounding
>> labelled BGP and RSVP P2P LSP's so that we have a more thorough  
>> treatment
>> of all use cases to hopefully make all of this more clear.  (In  
>> fact, I
>> got a good start on this text on this on the plane ride home :-).
>>
>> -shane
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Aug 2010 10:34:31 -0400

> multipath can be used to accomplish this.

John,

Flow is being used in the sense of draft-ietf-rtgwg-cl-requirement
which is very similar to microflow in diffserv.  It is also the same
sense of flow used in draft-kompella-mpls-rsvp-ecmp.

Kireeti does not use "flow" in the sense you describe in
draft-kompella-mpls-rsvp-ecmp.  From that draft:

   Note: all load balancing is subject to the overriding requirement
   of mapping the same "flow" to the same downstream.  (What
   constitutes a "flow" is beyond the scope of this document.)

 ...

   As noted above, the overriding concern is that flows are mapped to
   the same downstream link (except when the MLSP or some constituent
   sub-LSPs are changing); this is typically done by hashing fields
   that define a flow, and mapping hash results to different
   downstream LSRs.  Hash-based load balancing typically assumes that
   the numbers of flows is sufficiently large and the bandwidth per
   flow is reasonably well- balanced so that the results of hashing
   yields reasonable traffic distribution.

A large number of "flows" map to one component or path of an ECMP.
Unless you'd like to now argue that Kireeti also doesn't know what he
was talking about when he wrote this.  Note that the above are *all*
of the occurances of the word "flow" in the body of the text.

Read the drafts thoroughly, then comment.  Please.

Curtis

---

From: Yong Lucy <[email-masked]>
Date: Sun, 08 Aug 2010 16:36:25 -0500

Hi John,

> From: John E Drake [mailto:[email-masked]]
> Sent: Wednesday, August 04, 2010 8:49 AM
> To: Yong Lucy
> Cc: Shane Amante; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] [mpls] ELI as a reserved label
> 
> Lucy,
> 

[LY] No, this is not the "large flow" definition. The definition of the flow
in the draft is "A group of packets that contain the same flow "identity" in
their header. The network intends to transport the packets that belong to
the same flow over the same path so flow packet sequence is preserved." And
the large flow definition is "a flow comes to the network at the bit/packet
rate that is on the top bit rate rank among all the flows". 

> through the network towards the packets' destinations.

[LY] IMO: there should be only one definition for the flow. The large flow
is the flow that has very high bit/packet rate.   
> multipath can be used to accomplish this.

[LY] I did talk with Curtis about adaptive multipath and large flow
classification in IETF 78. The differences between two is that large flow
classification enables differentiated treatments on large and small flow
packets and performing proactive load balance while adaptive multipath has
the single treatment for all flow packets and adjusts the range when uneven
load occurs. In fact, we think that adaptive multipath for small flow
treatment is great so only small flows are moved when uneven load occurs. 

[LY] When a network needs to carry more aggregated traffic consisting of
many and many flows, we can't assume that the flows have roughly balanced
rates. Thus, hashing can't perform even load balance. Adaptive multipath
improves it by using ranges (hash to individual ranges) and adaptive mapping
the ranges to paths. The adjustment frequency may cause many flows out of
sequence. Combining two methods can reduce such adjustment frequency a lot.

Lucy

---

From: John E Drake <[email-masked]>
Date: Mon, 9 Aug 2010 14:13:30 -0700

Comments inline

Sent from my iPhone

> From: Yong Lucy [mailto:[email-masked]]
> Sent: Sunday, August 08, 2010 2:36 PM
> To: John E Drake
> Cc: 'Shane Amante'; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [PWE3] [mpls] ELI as a reserved label
> 
> Hi John,
> 

JD:  You actually gave two different definitions.  How do you identify the beginning and end of a large flow, and how do you know it is a large flow before it has ended?  I.e., if you don't know whether it is a large flow, how can you identify it as such?  Given that large flows will have different packet counts, how does a large flow indicator help a transit node perform better load balancing than simply counting the packets it sends along each path?