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

Greg Daley <> Tue, 26 February 2013 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1694C21F86E3 for <>; Tue, 26 Feb 2013 15:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.605
X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v1J-UVEjMyfo for <>; Tue, 26 Feb 2013 15:05:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B272421F8654 for <>; Tue, 26 Feb 2013 15:05:40 -0800 (PST)
Received-SPF: None ( no sender authenticity information available from domain of identity=mailfrom; client-ip=;; envelope-from=""; x-sender=""; x-conformance=spf_only
Received-SPF: None ( no sender authenticity information available from domain of identity=helo; client-ip=;; envelope-from=""; x-sender=""; x-conformance=spf_only
Received: from unknown (HELO ([]) by with ESMTP; 27 Feb 2013 10:05:39 +1100
Received: from ([]) by ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0342.003; Wed, 27 Feb 2013 10:05:39 +1100
From: Greg Daley <>
To: "'Knutsen, Andrew'" <>, "Mahdavi, Jamshid" <>, "''" <>
Thread-Topic: [middisc] Wan Optimization standardization problem statement/analysis?
Thread-Index: AQHOFErSndpMQHlrSUuvkpmczTr6AJiMtgIQ
Date: Tue, 26 Feb 2013 23:05:37 +0000
Message-ID: <>
References: <>, <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
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 23:05:42 -0000


Thanks for your responses.

I agree that there is a lot of deployed technology, which vendors have been deploying to gain optimizations.

I'm thinking that cataloguing existing deployed approaches could be one part of the a Problem Statement.  
Given the variety of approaches applied in even one vendors solution (Tunnels, TCP optimization, Compression/Dedup, Application specific optimizations), it may still be that any future solution doesn't bite off all of these at once.

I agree that there will be a lot of interaction between TSV and APP.  For latter versions of the problem statement, we may need to work in specific concerns from these areas.   My focus is currently getting a discussion level document out in the near future. 

With respect to the end-to-end model, we can explicitly address differences in the deployments from transparent/pure environments to middlebox arbitrated ones.  

I'd guess it's explicit goal of the WAN accelerators to present identical application data though, and present behaviour compatible with existing edge device TCP/IP stacks. 

Personally, I will not be at IETF, but will start working on a draft for when the submissions open up again.

I'm interested in input if people have hallway conversations during the meeting.



-----Original Message-----
From: Knutsen, Andrew [] 
Sent: Wednesday, 27 February 2013 4:58 AM
To: Mahdavi, Jamshid; Greg Daley; ''
Subject: RE: [middisc] Wan Optimization standardization problem statement/analysis?

   Well put...  I'll just reiterate that the more people who support this sort of technology within the IETF, the closer it will come to representing the needs of the users (and thus staying relevant).  While I do have respect for the purist end-to-end model, we've found that it can be taken too far.


From: [] on behalf of Mahdavi, Jamshid
Sent: Tuesday, February 26, 2013 7:52 AM
To: Greg Daley; ''
Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis?

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
middisc mailing list