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
This archive was generated by hypermail 2b29 : Mon Aug 27 2001 - 13:51:27 EDT