[Martin Visser <martinvisser99@xxxxxxxxx>]

Oh, I probably didn't answer one key question you asked, and yes in general you need an appliance near each end.  One box to do the magic on the way out and the other to undo it at the other end!

(Some of the vendors do have what amounts to a "soft" version of their appliance that runs on one end. This is particular useful for mobile/remote users, where your own notebook acts as an intelligent caching-compressing-proxy-appliance that communicates with the data centre end appliance, normally as part of a VPN solution).

Regards, Martin

MartinVisser99@xxxxxxxxx

On Sun, Mar 28, 2010 at 10:25 PM, Martin Visser <martinvisser99@xxxxxxxxx> wrote:

Riverbed do have white papers on their technology, but I think you will need to register with their website (if you have them in your WAN you probably have a support agreement and can get access to manuals etc).

Riverbed (like most of the other major players in this space) employ multiple technologies. http://en.wikipedia.org/wiki/WAN_optimization mentions these in summary. De-duplication (avoiding send the same data twice through locally storing data chunks and sending only a hash has an index), which Riverbed call Scalable Data Referencing or SDR,  is probably the most radical and effective technique they use. But plain-old compression, prepopulation (content delivery) and even TCP tunnelling (hugely increasing TCP window sizes) all have their application.

While most of the techniques are reasonably transparent (where the boxes restore original data and their headers) some are not. This is no different though from something as common-place as a NAT at a firewall. (Many of the vendors including Riverbed allow you to adjust the transparency of the boxes on the network, mainly so you can properly apply standard WAN quality of service or perform application utilisation modelling).

Certainly such boxes can make network troubleshooting "interesting" in some circumstances, however for us network engineers it is important to understand them, and at least be able accept and/or isolate their effect if necessary.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Sun, Mar 28, 2010 at 4:09 PM, vincent paul <amoteluro@xxxxxxxxx> wrote:

Hi Martin,

 

Thank you for your quick and precious explanation.  There are Riverbeds in our WAN. 

If possible could you please point me to papers/links about how Riverbed intercept packets between user and server (for example, does Riverbed inspect packet's payload to compress/de-compress, put back its original header, and forward the packet to its destination (or another Riverbed)

 

Once again, I greatly appreciate your help.

 

Regards,

PV

--- On Sat, 3/27/10, Martin Visser <martinvisser99@xxxxxxxxx> wrote:

From: Martin Visser <martinvisser99@xxxxxxxxx>
Subject: Re: [Wireshark-users] Immediate ACK from server
To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Date: Saturday, March 27, 2010, 11:29 PM

More than likely, assuming your measurements are correct,  there is a local "blackbox" between user and the server. This will possibly be an old-school application proxy (or a firewall acting as such a proxy), a device like Packeteer doing traffic-shaping, or a new-age WAN acceleration device (such as from Riverbed, or a Juniper WX or Cisco WAAS). 

These all can fake the ACK, and do so simply to either avoid the problems of delay on WAN traffic, either trying to serve cached traffic or manage the sliding Window to improve (or hinder) your throughput.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Sun, Mar 28, 2010 at 1:22 PM, vincent paul <amoteluro@xxxxxxxxx> wrote:

Dear All,

 

I am looking at a trace between user and database server.  And I know for sure the RTT between them is 90 ms.

However, I observe that evertime user sends a request to server,  there is one immediate ACK from server to ack this packet (i.e. delta time between user's packet and its immediate ACK from the server is much less than RTT.  For example 0.2 ms compared to RTT of 90 ms).

 

Please explain how such server's immediate ACK could happen.

 

regards,

PV

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

-----Inline Attachment Follows-----

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe