[The durned filters are a little too stringent. This one got
caught. Sorry. --allman]
------- Forwarded Message
Subject: Re: TCP question
To: tcpsat@grc.nasa.gov
From: "Navid Yazdani" <Navid_Yazdani@raytheon.com>
Date: Wed, 5 Sep 2001 16:34:13 -0400
My original post on modifying the MSS to match the rwnd was inteneded as a
technique for a congestion free satellite link -- not to be used across the
Internet. I agree that making such a modification on the Internet where
this TCP stream will be interacting with others may produce unstable
results. With a large MSS over the Internet there is an overhead of
segmentation issue, fairness issue with competing streams issue, and IP
packet loss recovery efficiency issue.
I have seen that Mentat makes a TCP spoofing box. Does anyone know of
other vendors of such boxes? What are current systems using?
Thanks
- -Navid
Gorry Fairhurst <gorry@erg.abdn.ac.uk>@grc.nasa.gov on 08/27/2001 01:36:07
PM
Sent by: owner-tcpsat@grc.nasa.gov
To: Sergey Raber <raber@gmd.de>
cc: tcpsat@grc.nasa.gov
Subject: Re: TCP question
If this is going to be discussed here, we need to start out with a
clearer understanding of what are the demerits and merits of this
technique, set against what we already know (or fear) about using
very large initial TCP windows, and the use of IP fragmentation.
Your suggestion seems different, but I suspect shares many of their
known problems.
I would like to understand the impact of what you have done on slow start
and congestion behavior. There has long been a fear of TCP hosts
emitting line-rate bursts of packets into the Internet, and the
potential damage this may cause to other flows sharing routers along
the path. Have you looked at a fully loaded satellite link, shared
between a number of applications - some using your protocol, and some
conventional TCP configurations?
Best wishes,
Gorry Fairhurst
Sergey Raber wrote:
>
> > > If the Sender Maximum Segment Size (SMSS) is set to the same value
> > > as the Receiver Window (rwnd), will the window used by the sender
> > > - defined as min(rwnd,cwnd) - always remain at a constant value of
> > > rwnd?
> > >
> > > For example, if the sender receives a rwnd of 64K, can it set the
> > > MSS to 64K and keep its window wide open all the time - even if
> > > there is congestion?
> >
> > Clever. ;)
> >
> > I think you're correct since there is a lower bound on cwnd (i.e.,
> > it can never be less than 1 MSS).
> >
> > But, I don't think this will actually work all that well -- and it
> > may be worse for the network than simply setting your TCP to never
> > adjust cwnd. The problem is that you are spitting out 64KB onto the
> > network at once. With a burst like that some packet is going to be
> > lost -- which means you'll end up retransmitting the TCP segment
> > again (in a 64KB burst). Packets from that segment will likely be
> > dropped, etc. So, you likely won't be getting much of anything
> > done.
>
> Anyhow, we have tested out the following:
>
> Test link: 8Mbps forward on the real GEO satellite (BER ~10E-8), 128Kbps
> reverse over sat. simulator. Total RTT ~550ms.
> Using standard tcp MSS (1448) with the max. window size of 589815Byte and
> downloading a 20MByte file (via ftp) we have got the speed of
> 280-610KByte/sec (depending on the packet losses that initiated
retransmit &
> congestion avoidance)
> Using tcp MSS 16208Byte we have reached improvement of the speed to
> 480-730KByte/sec on the same link with the same conditions. Slow start
> reaches max. cwnd about two times faster and congestion avoidance phase
> reaches max. cwnd about 10 times faster.
Which protocol stack are using and what platform?
>
> Is this really does not deserve any following discussion?
>
> Regards,
> ---
> Sergey Raber
> GMD.NET
> Project Satellite Communication
------- End of Forwarded Message
This archive was generated by hypermail 2b29 : Thu Sep 06 2001 - 07:41:05 EDT