Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3E83A6900 for ; Thu, 22 Jul 2010 13:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[AWL=-1.579, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkGxAlQExH3g for ; Thu, 22 Jul 2010 13:18:59 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6A2BA3A68F1 for ; Thu, 22 Jul 2010 13:18:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5Z0075N73UN3@szxga03-in.huawei.com> for mpls@ietf.org; Fri, 23 Jul 2010 04:19:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5Z00KSV73UOY@szxga03-in.huawei.com> for mpls@ietf.org; Fri, 23 Jul 2010 04:19:06 +0800 (CST) Received: from y736742 ([10.124.12.56]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5Z00MXZ73SU7@szxml04-in.huawei.com> for mpls@ietf.org; Fri, 23 Jul 2010 04:19:06 +0800 (CST) Date: Thu, 22 Jul 2010 15:19:03 -0500 From: Yong Lucy To: curtis@occnc.com, mpls@ietf.org Message-id: <011101cb29db$22185df0$380c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_VZ/6EwCmn8Wm6b42jsHyxQ)" Thread-index: Acsp2yCf3dZR3HqMRrK742qsMRUyRQ== Subject: [mpls] draft-villamizar-mpls-tp-multipath X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 20:19:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_VZ/6EwCmn8Wm6b42jsHyxQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Curtis, Thank you for summarizing hashing based multipath solution in this draft. Share my opinion here. Draft Text: An alternate simple multipath technique uses a table generally with a power of two size, and distributes the table entries proportionally among component links according to the capacity of each component link. An adaptive multipath technique is one where the traffic bound to each component link is measured and the load split is adjusted accordingly. End Text Comment: 1) Adjusting load over component link may cause flow reordering. 2) If a huge amount of micro flows mix with few large and long live flows, the load per entry can be out of balance 3) Measure component link load does not provide the info. for table entry mapping adjustment Internet traffic pattern today is different from decade or more years ago. Hashing works well under the condition 1) # of flows is very large and flow IDs are statistically random; 2) flow BWs are pretty balanced. Otherwise, hashing has a trouble to make even load balance. Hashing + bucket mapping brings a room to deal with the unbalance if each bucket load is measured. If the equipment understands flows better rather than just flow ID, more proactive way can apply to multipath load balance. This is why we suggest having large flow classification (draft-yong-pwe3-lfc-fat-pw-01) Regards, Lucy --Boundary_(ID_VZ/6EwCmn8Wm6b42jsHyxQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Curtis,

 

Thank you for summarizing hashing based multipath solution in this draft. Share my opinion here.

  

Draft Text:

 

   An alternate simple multipath technique uses a table

   generally with a power of two size, and distributes the table entries

   proportionally among component links according to the capacity of

   each component link.

 

   An adaptive multipath technique is one where the traffic bound to

   each component link is measured and the load split is adjusted

   accordingly.   

 

End Text

 

Comment:

1) Adjusting load over component link may cause flow reordering.

2) If a huge amount of micro flows mix with few large and long live flows, the load per entry can be out of balance

3) Measure component link load does not provide the info. for table entry mapping adjustment

 

Internet traffic pattern today is different from decade or more years ago.  Hashing works well under the condition

1) # of flows is very large and flow IDs are statistically random; 2) flow BWs are pretty balanced.

 

Otherwise, hashing has a trouble to make even load balance.  Hashing + bucket mapping brings a room to deal with the unbalance if each bucket load is measured.

 

If the equipment understands flows better rather than just flow ID, more proactive way can apply to multipath load balance. This is why we suggest having large flow classification (draft-yong-pwe3-lfc-fat-pw-01)

 

Regards,

Lucy

 

 

--Boundary_(ID_VZ/6EwCmn8Wm6b42jsHyxQ)--