Wireshark mailing list archives
Re: Immediate ACK from server
From: Martin Visser <martinvisser99 () gmail com>
Date: Sun, 28 Mar 2010 22:25:29 +1100
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 () gmail com On Sun, Mar 28, 2010 at 4:09 PM, vincent paul <amoteluro () yahoo com> 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 () gmail com>* wrote: From: Martin Visser <martinvisser99 () gmail com> Subject: Re: [Wireshark-users] Immediate ACK from server To: "Community support list for Wireshark" <wireshark-users () wireshark org> 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 () gmail com<http://us.mc1114.mail.yahoo.com/mc/compose?to=MartinVisser99 () gmail com> On Sun, Mar 28, 2010 at 1:22 PM, vincent paul <amoteluro () yahoo com<http://us.mc1114.mail.yahoo.com/mc/compose?to=amoteluro () yahoo com>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 () wireshark org<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users () wireshark org>Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users-request () wireshark org> ?subject=unsubscribe-----Inline Attachment Follows----- ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users () wireshark org>Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users-request () wireshark org> ?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Immediate ACK from server vincent paul (Mar 27)
- Re: Immediate ACK from server Martin Visser (Mar 27)
- Re: Immediate ACK from server vincent paul (Mar 27)
- Re: Immediate ACK from server Martin Visser (Mar 28)
- Re: Immediate ACK from server Martin Visser (Mar 28)
- Re: Dup ACK #1 vincent paul (Mar 30)
- Re: Dup ACK #1 Martin Visser (Mar 30)
- Re: Dup ACK #1 vincent paul (Mar 31)
- Re: Dup ACK #1 vincent paul (Mar 31)
- Re: Dup ACK #1 Martin Visser (Mar 31)
- Re: Immediate ACK from server vincent paul (Mar 27)
- Re: Immediate ACK from server Martin Visser (Mar 27)