Subject: Re: TCP question

From: Mark Allman <[email-masked]>
Date: Tue, 21 Aug 2001 16:18:58 -0400

> 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.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 21 Aug 2001 21:39:23 +0100 (BST)

> it can never be less than 1 MSS).

It strikes me that that might be a useful hack for the upper TCP in
the hideous-go-through-firewalls hack that is TCP-in-TCP tunnelling.

[ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

grumbles about TCP congestion interaction and what happens if you
don't block and drop on your streaming inputs - an infinite queue,
in other words.]

> dropped, etc.  So, you likely won't be getting much of anything

in the TCP-in-TCP case, you'd still want to tweak timeouts etc. (And
obviously this isn't much use if your inner and outer TCPs aren't
sitting on the same stack in the same box; it's only if they are that 
you start thinking of big mtus.)

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Sergey Raber" <[email-masked]>
Date: Mon, 27 Aug 2001 19:00:01 +0200

> dropped, etc.  So, you likely won't be getting much of anything

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.

Is this really does not deserve any following discussion?

Regards,
---
Sergey Raber
GMD.NET
Project Satellite Communication

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 27 Aug 2001 18:36:07 +0100

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

> reaches max. cwnd about 10 times faster.

Which protocol stack are using and what platform?

---

From: "Charlie Younghusband" <[email-masked]>
Date: Mon, 27 Aug 2001 16:16:18 -0400

It does not surprise me that you received performance gains.    Looking at
the simple single connection over an uncongested direct satellite link as
part of another project I worked on, we did a simple mathematical formula
where we asked how low does the BER have to go before the largest (RFC
compliant) TCP MSS size available was no longer optimal, and factoring in
header overhead the answer was ridiculously low (like 10e-3).    By
extension, it was clear that a larger MSS was much more efficient on the
higher bandwidth links seen today.  I'm not sure where you got the 16208 MSS
size, but I suspect that it is link bandwidth specific and if for some
reason your bandwidth was seriously suddenly reduced (such as a competing
data stream) you'd suddenly have virtually no bandwidth available to either
data stream as neither would complete a TCP segment very often.  Still, it
is an interesting tuning idea for a single TCP connection over a satellite
link with no other competition when the bandwidth is known and fixed.  Other
than that case, things fall apart quickly as there is poor scaling and
little adaption. As Gorry Fairhurst pointed out, run it with anything else
and then see.  There are other better options. (I'll also point out that
you're still only at best about 73% link efficiency with your modifications,
so even if this specific case always applies to your usage, wasting over
2Mbps of satellite bandwidth probably won't please whoever pays for it :))

Cheers,
Charlie

---
Charlie Younghusband
Network Software Engineering
Xiphos Technologies		http://www.xiphos.ca/
514-848-9640

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Sergey Raber
Sent: August 27, 2001 1:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: TCP question

Regards,
---
Sergey Raber
GMD.NET