Re: Immediate ACK from server

[Martin Visser <martinvisser99 () gmail com>]

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 () gmail com


On Sun, Mar 28, 2010 at 10:25 PM, Martin Visser <martinvisser99 () gmail com>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 () 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