Lets expand slightly
the advertised window is receiver invoked flow control and is what is
store in the header. it indicates how much data the receiver is
capable of buffering IF the sender want to send that much.
the congestion window is sender invoked flow control and is not store
in the header. it is an artificial sender reduced window limit of how
much (depending upon measured available path bandwidth and indications
of where congestion occurs in the network).
the only way to deduce the congestion window from a trace of a sender
is by having intimate knowledge about the specific sender
implementation and knowledge about under what exact
circumstances it opens/closes this window since all implementations do
this slightly differently.
IF you take a trace on the sender and IF you have very good timestamp
resolution and IF the roundtrip time is much higher than the timestamp
resolution
you CAN infer what the congestion window is likely to be by manually
monitoring when data is acked and new data is sent and by how much
data is kept in flight before the sender pauses waiting for an ACK for
no other good reason.
This requires very detailed knowledge about exactly how that
particular stack works and is very time consuming.
Oh, it also only works if the capture was taken on the same host that
is sending the data.
On 11/15/05, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> He asked for the congestion window.
> not the advertised window.
>
>
> On 11/15/05, Andersen Jens Elmo <jens.elmo.andersen@xxxxxxxxxxx> wrote:
> > Uh ???
> >
> > The TCP window size is present in every single TCP packet.
> > As such you should be able to extract the value and plot it.
> > However, I dont know if Ethereal can do it
> >
> > The receiving station will sent the windowsize telling how much data the
> > transmitting station can send with out waiting for an acknowledge.
> > Typical 16K byte
> > It will decrease the window size in face of packet loss to adjust the
> > sender to the available bandwith.
> > Normally you dont need to worry about this
> >
> > It will also decrease if the reciever runs out of buffer space.
> > In this case, you should rather fix the problem than monitor.
> > No need to plot a graph if you see this behgaviour - use more CPU power
> > and more memory in the server.
> >
> > The initial value can vary from machine to machine, and it also depends
> > on wether you use "slow start"
> > In "slow start" the server starts up with a fairly small window and
> > increases the size until packets starts getting dropped. This is the
> > best behaviour seen from the network.
> > Without "slow start" the server will start out with maximum windowsize
> > which will give the user the best performance but can load the network
> > for a short period.
> >
> >
> > Regards
> >
> > Jens Elmo
> >
> >
> > -----Original Message-----
> > From: ethereal-users-bounces@xxxxxxxxxxxx
> > [mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of ronnie
> > sahlberg
> > Sent: 15. november 2005 09:43
> > To: Ethereal user support
> > Subject: [Ethereal-users] Re: Plotting TCP Congetion Window evolution
> >
> > No,
> >
> >
> > it is not possible using any tool.
> >
> >
> > the congestion window is an artificial limit imposed internally by the
> > TCP sender.
> > its size is not stored inside the packet.
> > neither is it possible to determine it by looking at a trace.
> >
> >
> > different implementations also use different/tweaked methods how they
> > manage the congestion window internally making it more difficult.
> >
> >
> >
> > you really need to know the exact algorithms in great detail about the
> > exact specific implementation of the host sending the data in order to
> > be able to "guess" what the congestion window is set at at a specific
> > point in time.
> >
> >
> >
> >
> >
> > On 11/15/05, Prasad Kularatne <kularatn@xxxxxxxxxx> wrote:
> > > Hi folks,
> > >
> > > Does anybody know whether it is possible to plot the TCP Congestion
> > > Window evolution using Ethereal?
> > >
> > > Please advise. Thanks.
> > >
> > > Good Luck!
> > > Prasad
> > >
> > >
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
>
