[mpls] Question about draft-yong-pwe3-enhance-ecmp-lfat-01

"Mallette, Edwin" <Edwin.Mallette@bhnis.com> Thu, 25 March 2010 18:24 UTC

Return-Path: <Edwin.Mallette@bhnis.com>
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 A46823A6E51 for <mpls@core3.amsl.com>; Thu, 25 Mar 2010 11:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.806
X-Spam-Level:
X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
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 7h3e9ZnND+rQ for <mpls@core3.amsl.com>; Thu, 25 Mar 2010 11:24:49 -0700 (PDT)
Received: from mx3.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by core3.amsl.com (Postfix) with ESMTP id EE3FA3A6920 for <mpls@ietf.org>; Thu, 25 Mar 2010 11:22:25 -0700 (PDT)
Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id o2PIJdOq030590 for <mpls@ietf.org>; Thu, 25 Mar 2010 14:22:47 -0400
Received: from cntpacas1.corp.local ([10.225.1.123]) by mx3.mybrighthouse.com with ESMTP id mrbk9gyg1-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mpls@ietf.org>; Thu, 25 Mar 2010 14:22:47 -0400
Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpacas1.corp.local ([10.225.1.123]) with mapi; Thu, 25 Mar 2010 14:22:46 -0400
From: "Mallette, Edwin" <Edwin.Mallette@bhnis.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Date: Thu, 25 Mar 2010 14:22:27 -0400
Thread-Topic: [mpls] Question about draft-yong-pwe3-enhance-ecmp-lfat-01
Thread-Index: AcrMSB/PxmCD7ZL7QimZPk7p2YXYmA==
Message-ID: <6569379E42CFCB4192ECE021966F9A444AE8FEB622@CNEMAIL.corp.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6569379E42CFCB4192ECE021966F9A444AE8FEB622CNEMAILcorplo_"
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-0911030000 definitions=main-1003250168
Subject: [mpls] Question about draft-yong-pwe3-enhance-ecmp-lfat-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 18:24:56 -0000

Hi Lucy,

There wasn't enough time in the PWE session to address my question, so I brought it to the list.  I have a number of questions here, but I'll focus on the one most pertinent to the "use-ability" of this draft in my mind.

In reference to your simulation, I understood you to say that you only ran it with constant rate flows.  The crux of my question has to do with the variable nature of the "small" flow and the "large" flow.   So if you have a flow that starts off as a small flow and then gets processed by the Small Flow Forwarding process.  The small flow gets hashed normally and follows some path we'll call PATH_A according to some PHB ECMP mechanism.  When this flow becomes a large flow is the intent that the flow will then be forwarded to the Large Flow Forwarding Process ?

I'm going to assume for the moment that the answer is yes, this has to be so.  So given that my assumption is accurate, how do you handle the condition that will variably arise when the Large Flow Forwarding Process forwards the flow over PATH_B, which may have less aggregate delay than PATH_A.    If you instantaneously switch a flow from one path to another with less delay you will end up with out of order packets at the receiver, unless you do some magic, right ?  How would you propose to handle this ?

Cheers!

Ed



________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.