Re: [mpls] [PWE3] FW: Large FLow Classificaiton in Flow Aware Transport

[Yong Lucy <[e-mail]>]

Hi John,

Uneven load balance problems exist today. There are several drafts to target
this problem.

Thanks,
Lucy

> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Tuesday, July 20, 2010 1:44 PM
> To: [e-mail]; Yong Lucy
> Cc: [e-mail]; 'pwe3'
> Subject: RE: [mpls] [PWE3] FW: Large FLow Classificaiton in Flow Aware
> Transport
> 
> Lucy,
> 
> As Curtis points out in section 4.1.2 of
> http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath/, the
> issue your I-D purports to solve has been already been solved by clever
> implementation many years ago, with no changes to protocols or packet
> formats.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Curtis Villamizar
> > Sent: Tuesday, July 20, 2010 11:33 AM
> > To: Yong Lucy
> > Cc: [e-mail]; 'pwe3'
> > Subject: Re: [mpls] [PWE3] FW: Large FLow Classificaiton in Flow Aware
> > Transport
> >
> >
> > In message <00d801cb2519$e6f16160$[e-mail]>
> > Yong Lucy writes:
> > >
> > >
> > > I like to post this e-mail again for reminding. We have changed the
> > draft
> > > title to draft-yong-pwe-lfc-fat-pw to focus on large flow
> > classification,
> > > not enhanced ECMP.
> > >
> > > Look forward to discussing this at Maastricht.
> > >
> > > Lucy
> >
> >
> > Lucy,
> >
> > Any modifications to the use of the TC bits is almost certainly a
> > non-starter.  I thought that was also mentioned in the last meeting.
> > We'll see what comments come out of the meeting this time.
> >
> > Curtis
> >
> >
> > >   _____
> > >
> > > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Yong
> > > Lucy
> > > Sent: Tuesday, April 27, 2010 5:37 PM
> > > To: 'pwe3'; [e-mail]
> > > Subject: [mpls] Large FLow Classificaiton in Flow Aware Transport
> > >
> > >
> > >
> > > Hi,
> > >
> > > I recap the comments raised during IETF77 meeting. Some are from the
> > PWE3
> > > meeting and some from offline discussions. Hope this gives some
> > > clarification and bring up further mailing discussion.
> > >
> > > The draft proposal (draft-yong-pwe3-enhanced-ecmp-lfat-01) is to use
> > one of
> > > the TC bits in the flow label to indicate large flow. TC bits in flow
> > label
> > > described in FAT-PW are not used and are not interpreted by LSR.
> > >
> > > Comments and Responses:
> > >
> > > 1) No use for the proposal. would need to update all equipment to get
> > this
> > > to work.  A while ago we agreed to not standardize ECMP process.
> > >
> > > Lucy: Some carriers see the value of it. There is no need to update
> > all
> > > equipment to get this work. The backward compatibility is supported
> > as
> > > described in section 6. Partially upgrading can improve some segments
> > while
> > > keeping other segments remain the same. The intention of the draft is
> > not
> > > for standardizing ECMP process. It is about standardizing large flow
> > > classification indication in PSN. The draft layout may lead this
> > confusion.
> > > We will modify the draft and move enhanced ECMP process description
> > to
> > > appendix as one implementation example to use large flow
> > classification. We
> > > will change the draft title to "large flow classification in flow
> > aware
> > > transport over PSN" and upload soon.
> > >
> > > 2) would need to go through MPLS WG for issue on standardizing ECMP.
> > Label
> > > stack is always MPLS label stack so MPLS WG would need to OK change
> > of TC
> > > semantics.  Needs a co-review in MPLS WG and they must approve.
> > >
> > > Lucy: The draft is not for standardizing ECMP. (sorry for the
> > confusion).
> > > The draft does not change the semantics of a label stack entry
> > defined by
> > > RFC3032 because the flow label is never on the top of label stack. As
> > FAT-PW
> > > draft indicates that the interpretation of TC bits in the flow label
> > by LSR
> > > is undefined. This draft proposes one definition.
> > >
> > > 3) If you can get MPLS WG to agree, one of the issues is that you are
> > > marking at a PE where the PE may or may not know what is or isn't a
> > big
> > > flow.  Limitations on PEs ability to determine what a big flow is.
> > Would
> > > need to tell easily and ubiquitously what a big flow is.
> > >
> > > Lucy: In our proposal, large flows in this context are the top rate
> > ranked
> > > flows. It is relevant to other flows not the link capacity. Enhanced
> > ECMP
> > > process just needs a small set of large flows for load balancing,
> > therefore,
> > > it can pick by statistics, i.e. not necessary all the large flows.
> > The
> > > method works well even some large flows placed by hashing function.
> > The
> > > backward compatibility in the draft would deal with this.
> > >
> > > 4) we haven't standardized anything on ECMP. Many will look at bottom
> > of
> > > stack to look at IP address or anything else to hash on. If I'm a PE
> > router
> > > with lots of L3VPN traffic and some PWs, how do I know if this is a
> > flow
> > > label or VPN label.
> > >
> > > Lucy: This is not for ECMP standardization. We propose one method to
> > > differentiate the flow label from IP packet, PW label, and LSP label
> > at the
> > > bottom of label stack. This is: check the first nibble to separate IP
> > and
> > > MPLS packets; for MPLS packets, use TTL value (=0) to check the flow
> > label
> > > packets.
> > >
> > > 5) this is addressing an important issue.  Simulations showed a lot
> > of
> > > traffic and the flows are large enough.  Cases in well engineered
> > network
> > > where situation is much worse than shown.  Drafts have been
> > submitting in
> > > past that gained no traction.  To use a method other than just
> > hashing, but
> > > may be ways to do this without changing label or MPLS.
> > >
> > > Lucy: The simulation use Internet traffic pattern. For carrier
> > network, it
> > > has a lot of L2VPN traffic carried as single flow, so the situation
> > is
> > > worse. We work on additional simulation to include such type of
> > traffic. It
> > > confirms the statement. As Internet traffic grow with higher and
> > higher bit
> > > rate flows, the problem will become more and more severe. We need to
> > aim on
> > > this real problem.
> > >
> > > 6) there was a proposal to solve this 10 years ago with no protocol
> > changes.
> > > This is not needed.
> > >
> > > Lucy: Need clarification which proposal refers to. If it is OMP, the
> > draft
> > > proposes the different method from OMP. OMP suggest using routing
> > protocol
> > > to advertise individual ECMP path TE information in the network. The
> > draft
> > > is about large flow classification indication so LSR can use a set of
> > large
> > > flows in performing load balance over ECMP paths effectively.
> > >
> > > 7) Changes too much about MPLS processing
> > >
> > > Lucy: It is not that additional process. Gaining is obvious too.
> > >
> > > 8) did the simulations deal with coming and going of flows? How to
> > address
> > > flow fluctuation?
> > >
> > > Lucy: we are working on additional simulations. That will include
> > flow
> > > coming and going situation and include much higher bit rate flows,
> > and a
> > > "permanent flow" whose rate may change over time to make it as small
> > flow at
> > > a time or a large flow at another time. The latter case likes a VPWS
> > as a
> > > flow. Be glad to show some simulation result to the group.
> > >
> > > 9) Signaling can be used for this, why using marking?
> > >
> > > Lucy: today, signaling a PW is used per a service basis such as VPWS
> > or
> > > VPLS. But one VPWS or VPLS may contain many flows, the draft address
> > this
> > > situation. It is hard for carrier to signal individual large flow
> > within
> > > VPLS over PSN networks.
> > >
> > > 10) If there is incentive to enhanced ECMP, why not do large flow
> > > recognition at local LSR for the purpose? PE based large flow
> > recognition
> > > and marking do not apply well at individual LSR.
> > >
> > > Lucy: High bit rate flow is relevant to other flows. Operator can set
> > large
> > > flow criteria. Having each LSR performs larger flow recognition add
> > complex
> > > to each LSR and may impact the service performance. Large flow
> > > classification is easier, we think. Today, DiffServ enables the
> > network to
> > > perform different service treatments. Large flow classification
> > enables
> > > network to perform different flow treatments over ECMP operation.
> > >
> > > Comments and suggestion are welcome.
> > >
> > >
> > > Regards,
> > > Lucy
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls