Re: [middisc] Wan Optimization standardization problem statement/analysis?

"Mahdavi, Jamshid" <> Tue, 26 February 2013 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1105221F8899 for <>; Tue, 26 Feb 2013 07:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n9qzoVdSlGPD for <>; Tue, 26 Feb 2013 07:52:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 832D821F8890 for <>; Tue, 26 Feb 2013 07:52:47 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 096E781A0A7; Tue, 26 Feb 2013 06:52:47 -0900 (AKST)
Received: from ([fe80::c596:c77:dd67:b72d]) by ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 26 Feb 2013 07:52:46 -0800
From: "Mahdavi, Jamshid" <>
To: Greg Daley <>, "''" <>
Thread-Topic: [middisc] Wan Optimization standardization problem statement/analysis?
Thread-Index: Ac4TuQYO4eE8uC6sRoqt1ktiiKZ70QAHChDA
Date: Tue, 26 Feb 2013 15:52:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Feb 2013 15:52:50 -0000

I'd definitely be in favor of seeing standard solutions, as they would be better for customers for exactly the reasons you describe.  I'm happy to see your suggestion!

If I might be so bold as to offer an opinion about how such an effort might fit into the IETF framework, there are typically two distinct parts to a WAN Op solution:

1.  A tunneling protocol in which to carry optimized traffic between symmetric WAN Op devices.  This portion also requires application level routing component, which can be explicitly set up, or done implicitly via a discovery technique such as we have covered in this draft.  

In the original version of this draft, we did include an explicitly reserved portion of the ID space for standard protocols, and another for vendor-specific discovery protocols.  At the time there did not seem to be an appetite for a standardized solution, so that does not appear in the current draft.

We didn't actually suggest any standard solution, just allowed some space for it.  And, is still easily done within the current draft by having the IETF claim an ID when such a standardization effort took place.

The tunneling protocol includes a lot more than just discovery -- it may encompass many of the same elements as TCP itself and may also encompass encryption -- and all of that would also need to be standardized.  When Andrew and I came down to Anaheim two years ago to start this, I attended the "mptcp" working group and remember being struck that there were a lot of similarities between that work and the types of tunneling protocols needed for WAN Op.  I haven't tracked how it has proceeded since then, though.

I'd see all of the above elements as fitting within TSV area.

2.  A compression / optimization protocol, or a series of them, which may be application specific.  For most of the vendors this is probably where there is a lot of "secret sauce" and it would be hard to see practically how one might move forward with standardization.  However, there are a number of published protocols which could form the basis for such a standard and provide some basic cross-vendor interoperability -- perhaps not with the full benefits of a single-vendor solution, but still valuable.

I'd see such work as needing to proceed within the APP area.

All told, I think this would be a heavy lift to get done, but valuable if it could be.  I don't know of any other organization that would make more sense for this than IETF.  However, one challenge with the IETF is that there is a certain reluctance to standardize (or "bless" if you will) some of the things we need to do as middleboxes to make these type of solutions possible.

I think that more pull from customers, and people like you who can speak on behalf of customers, would help work like this to gain traction.


-----Original Message-----
From: [] On Behalf Of Greg Daley
Sent: Monday, February 25, 2013 4:35 PM
To: ''
Subject: [middisc] Wan Optimization standardization problem statement/analysis?

Dear Middisc list, 

Thanks for your work on the Middlebox Negotiation Option draft.

I understand that this list and the draft are not focussed upon standardization of intercompatibility between Middleboxes, but I see it as a positive first step.

Working within the System Integration space, we are seeing significant impact upon customers due to incompatibilities between WAN optimization systems, particularly. 
Our company resells platforms from two Wanopt vendors, and several of our long term customers have deployments from further vendors.

We are seeing increased operational expenses for customers from managing incompatible systems, and difficulties in managing mergers of networks with different heritages.

Has anyone undertaken a review within the IETF of the general problem and scope of standardized WAN optimization?

Are there any organizations other than under IETF guise where this work is being done?

I understand that there are several legal issues associated with the work, and that some of this is before the courts.  

Please let me know if you are interested in furthering this work, and if you would be except for current legal circumstances.


Greg Daley


middisc mailing list