Subject: [Tsvwg] viewgraphs for a talk in tsvwg in Yokohama tomorrow

From: Sally Floyd <[email-masked]>
Date: Wed, 17 Jul 2002 04:41:40 -0700

I am giving a talk in tsvwg tomorrow in Yokohama on the two
drafts on HighSpeed TCP:

HighSpeed TCP for Large Congestion Windows,
draft-floyd-tcp-highspeed-00.txt

and:

Limited Slow-Start for TCP with Large Congestion Windows,
draft-floyd-tcp-slowstart-00.txt

The viewgraphs are at:
http://www.icir.org/floyd/talks/floyd-tsvwg-Jul02.ps
http://www.icir.org/floyd/talks/floyd-tsvwg-Jul02.pdf

There is also a HighSpeed Web Page at:
http://www.icir.org/floyd/hstcp.html

------

If there is time, I might also talk briefly about a somewhat
more speculative draft: 

Quick-Start for TCP and IP,
draft-amit-quick-start-00.txt

The viewgraphs for this are at the end of the other viewgraph file.

Quick-Start is designed to allow connections to start up more
quickly than slow-start, after a pass of feedback from all of
the routers along the path.

Thanks,
- Sally

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Andrei Gurtov" <[email-masked]>
Date: Thu, 18 Jul 2002 15:08:07 +0300

Sally-

I have a few comments on Limited Slow-Start for TCP with Large Congestion
Windows.

I've been looking at the slow start overshoot in the context of slow
wireless networks. The control block interdependence seems to be a very good
way to deal with it, as it stores ssthresh from a previous connection and
nicely avoids the overshoot (e.g. Figure 7, p. 28 in
http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html). It also seems to
be more conservative than just starting with unlimited initial ssthresh.

An interesting question is whether the slow start overshoot could be
prevented by an active queue management in the bottleneck queue. RED is not
helpful here as the drop probability is based on the moving average of the
queue size which is generally too slow to react to the exponential TCP
slow-start. I proposed a method for queues with a low level of multiplexing
which is to drop a single packet from a TCP connection when the queue is
over a soft threshold and then wait for a while to let TCP to move from slow
start to congestion avoidance (p. 64). Could something like that be done in
a larger scale? Probably not without keeping some per-connection state in
the router.

Would it be helpful also to include a discussion on another proposed
solution which is the overdamping algorithm in the FACK paper?

Andrei

---

From: Marco Mellia <[email-masked]>
Date: Thu, 18 Jul 2002 14:58:40 +0200

Sally,
may be I'm a bit confused, and I hope that you can help me.

My concern about HighSpeedTCP is related to the value of the cwnd you take as 
example.
Nowadys, it seems that the maximum wnd used during transmission by real 
systems is about 32* or 64* MSS (don't forget the rwnd that limits the wnd 
value...). And this is because the end-systems must keep track of all the 
transmitted segments that fit into current transmission window, so that in 
case of packet loss they can retransmit the lost segment.

Neglecting all the possible bottlenecks, but just considering the amount of 
memeory required to keep track of the in fligh packets, we have

 83333*1500 bytes ~ 119Megabytes!

On both sender and receiver side... for every TCP connection
Is this realistic?

I personally don't feel as a big problem the fact that it takes too much time 
to reach window as large as 83333. Simply no end system will ever be able to 
exploit 10Gbps speed with RTT 100ms.

Unless we radically change the sliding window protocol that is at the TCP 
root.

Hope this helps.

+-----------------------------------+
| Marco Mellia - Assistant Professor|
| Tel: 39-011-5644173               |
| Politecnico di Torino             |
| Corso Duca degli Abruzzi 24       |
| Torino - 10129 - Italy            |
| http://www1.tlc.polito.it/mellia  |
+-----------------------------------+

---

From: stanislav shalunov <[email-masked]>
Date: 18 Jul 2002 22:43:09 +0900

>  83333*1500 bytes ~ 119Megabytes!

Right now, we routinely operate in an environment with 70ms*100Mb/s =
875kB and sometimes operate with 70ms*1Gb/s = 8.75MB pipe capacity.[1]
Note that in practice this usually requires TCP buffer space about
twice this amount.

At this point, we have trouble getting TCP congestion control
algorithm to do the right thing -- not because of any backbone issues
but because of switches and hosts.

In perhaps 3-5 years we will likely have 87.5MB pipe capacity between
pairs of hosts.  If anything, I would argue that HighSpeed TCP horizon
of 10Gb/s doesn't extend far enough: should we need to change
congestion control every 5 years?

> I personally don't feel as a big problem the fact that it takes too
> much time to reach window as large as 83333. Simply no end system
> will ever be able to exploit 10Gbps speed with RTT 100ms.

How much are you willing to bet on it?

Seriously, why?  Are you saying that TCP is the problem?  In this
case, HighSpeed TCP or a slightly different by similar in nature (be
more aggressive when already sending at high rate) approach will help.
Or do you believe there's some other unspecified problem?

To propose an answer to the question that I put into the subject line:
until infinity would be good.

[1] People do need to move terabytes and even up to a petabyte today.
    (You too might need to do that in a few years.)  Right now, their
    most practical method is to ship tapes via FedEx.  It's a shame.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

---

From: Marco Mellia <[email-masked]>
Date: Thu, 18 Jul 2002 17:02:16 +0200

> but because of switches and hosts.

So basically you agree with me. The problem is not the congestion control, but 
rather how to _enable_ HighSpeed... 
The latest Sally's draft basically addresses a problem that does not exists, 
at least now...

> congestion control every 5 years?

Probably we are close to the point that we might start thinking about a 
radical change... We really want to use TCP to tell our nephews on Mars that 
we are doing fine?

> How much are you willing to bet on it?

Zero as usual. :)

> more aggressive when already sending at high rate) approach will help.

HighSpeed TCP is yaptt (Yet Another Patch To TCP) that addresses a problem 
that will (perheps) start to be felt in (few) years. Nowadays, the problem 
with TCP are related to short file transfers, with its inability to recover 
from losses when in small window regime.
I was thinking if it could be better to radically change TCP. 

> Or do you believe there's some other unspecified problem?

The problem is how to handle connection at 1Gb/s on 100ms RTT, which requires 
again about 20MBytes of memory... on both server and client side...

> until infinity would be good.

Congestion control must be done. No dubts. But the current way it is handled 
in TCP can not be patched forever.

And there will be a point in which TCP congestion control must be changed...

For example, what happen if teh internet will become a connection oriented 
network? At least, wouldn't be better for example to set up a new high speed, 
fixed rate connection to download your favorite DVD on your 10Gb/s network?

Then, who cares about TCP congestion control?

-- 
Ciao,                    /\/\/\rco

---

From: stanislav shalunov <[email-masked]>
Date: 19 Jul 2002 09:37:13 +0900

Marco Mellia <[email-masked]> writes:

> So basically you agree with me. The problem is not the congestion
> control, but rather how to _enable_ HighSpeed...  The latest Sally's
> draft basically addresses a problem that does not exists, at least
> now...

I'm telling you why the problem exists even today, and you're telling
me that we `agree' and go on saying that it doesn't exist.

> Probably we are close to the point that we might start thinking
> about a radical change... We really want to use TCP to tell our
> nephews on Mars that we are doing fine?

No Mars communication is necessary to get there: my examples are 70ms
RTT (which is the normal North American transcontinental RTT).

> HighSpeed TCP is yaptt (Yet Another Patch To TCP) that addresses a
> problem that will (perheps) start to be felt in (few) years.

It is a problem today.  Because of this problem (as well as huge
packet-per-second rates associated with microscopic 1500-byte MTU, but
let's leave this one aside for IEEE to ponder), people are saying that
they need transport protocols other than TCP or that packet networks
don't serve their needs well and they needs lambdas.  (People with
enough money to pay for a few backbones, mind you.)  They're tired of
sending tapes.  If we continue to bury our heads in the sand, they'll
get their own communication lines from the phone companies and won't
run IP over them.  If they can get their data transfers to work with
TCP, they'll instead pay for upgrades of IP networks -- and other IP
network users (even those who think that the web is still a `killer
app') will benefit from these upgrades.

> The problem is how to handle connection at 1Gb/s on 100ms RTT, which
> requires again about 20MBytes of memory... on both server and client
> side...

Surprise!  Computers exist -- today -- that have more than 20MB of RAM
(check the RAM size of yours; if it's less than 20MB, you might
contact an antique auction).  In fact, 20MB is a window size I used in
practice.  Others have used 20 parallel TCP streams with 1MB window
size each.

> Congestion control must be done. No dubts. But the current way it is
> handled in TCP can not be patched forever.

Interesting assertion.  If you were saying that HighSpeed TCP should
be amended so that it would require no further changes, ever --
including when our (great-)*grandchildren start preparing for 1Yb/s
upgrades -- I would agree with you.

> For example, what happen if teh internet will become a connection
> oriented network? At least, wouldn't be better for example to set up
> a new high speed, fixed rate connection to download your favorite
> DVD on your 10Gb/s network?

If the Internet dies and is replaced with a circuit-switched network
again, many things will become moot.

"I didn't attend the funeral, but I sent a nice letter saying that I
approved of it."				-- Mark Twain

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 18 Jul 2002 21:04:25 +0200

Hi again,

I also have a comment about this draft that I voiced during the meeting, 
but I would like to repeat it for those who couldn't attend ...

 From own experience, I'm convinced that the per-route metrics implemented 
in BSD4.4-Lite (see Stevens Vol.2) is an extremely elegant solution to the 
slow start overshoot problem: A TCP that terminates stores its ssthresh in 
the per-route metrics, and subsequent TCPs going via the same (explicit) 
route initialize their ssthresh from there. Those were early attempts of a 
congestion manager ...

Since this is widely deployed TCP code that has also served as a basis for 
other TCPs, I think that this should at least be addressed in some way in 
your draft; even if the per-route metrics stuff has never been written up 
as an Internet Draft or RFC.

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 18 Jul 2002 20:36:07 +0200

Hi Sally,

I have few comments about that draft ...

1. I'm not convinced that this is a real problem for the (public) Internet:
- Applications that only send a few 10 Gigabytes every now and then won't 
benefit from HighSpeed-TCP since the TCP sender will have to reset, or at 
least decay its congestion window during the idle phases. Such applications 
suffer most of all from the slow start.
- If this is a problem for people who run back-to-back-terra-bytes-moving 
applications on a private net, then why don't they simply change their 
sender's congestion control all together? And if this was the case, why 
would we need to bother about such private problems in the IETF?
- Maybe we need a requirements ID first?

2. p is not equally distributed:
- In a regime of CWNDs on the order of 100.000 segments (probably even 
sooner), why would a single packet loss per window be treated the same as a 
loss of half a window worth of segments? This was always something that 
bugged me about TCP-SACK.
- I could envisage a scheme where the sender doesn't even do a congestion 
control response to N packet losses in a window of W, if N << W, e.g., N < 
0.01 * W; but would more drastially react if, e.g.,  N > W/2.

The speeding ticket I get for going 105 miles per hour on the highway costs 
me more than the speeding ticket I get for going only 75 miles per hour.

///Reiner

---

From: Joe Touch <[email-masked]>
Date: Sat, 20 Jul 2002 15:15:34 -0700

Reiner Ludwig wrote:
>  From own experience, I'm convinced that the per-route metrics 
> implemented in BSD4.4-Lite (see Stevens Vol.2) is an extremely elegant 
> solution to the slow start overshoot problem: A TCP that terminates 
> stores its ssthresh in the per-route metrics, and subsequent TCPs going 
> via the same (explicit) route initialize their ssthresh from there. 
> Those were early attempts of a congestion manager ...

That's an extension of T/TCP's state reuse in the routing table, as 
described in RFC2140.

IMO, the CM is less about setting the state of individual flows based on 
shared info, than about integrating the state in a "sending system".

> Since this is widely deployed TCP code that has also served as a basis 
> for other TCPs, I think that this should at least be addressed in some 
> way in your draft; even if the per-route metrics stuff has never been 
> written up as an Internet Draft or RFC.

See T/TCP and RFC2140.

Joe

---

From: Mark Allman <[email-masked]>
Date: Sun, 21 Jul 2002 22:45:33 -0400

> implemented in BSD4.4-Lite (see Stevens Vol.2) is an extremely
> elegant solution to the slow start overshoot problem: A TCP that
> terminates stores its ssthresh in the per-route metrics, and
> subsequent TCPs going via the same (explicit) route initialize
> their ssthresh from there. Those were early attempts of a
> congestion manager ...

I am not familiar with the implementation at all, so I am trying to
understand this....  My workstation has one route entry --- all
traffic goes one way.  So, does that mean that all my connections
share some cached ssthresh value?  That would not seem right to me.
On the other hand, if all my connections to a.b.c.d share an
ssthresh value that seems more reasonable.

Thanks,
allman

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

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 23 Jul 2002 12:49:37 +0100 (BST)

> ssthresh value that seems more reasonable.

This the same BSD that said 'oh, from that destination address he's on
the same subnet as us, so we won't bother with slowstart at all?'

(very early attempts at optimising congestion management.)

L.

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

---

From: Richard Wendland <[email-masked]>
Date: Wed, 24 Jul 2002 03:30:50 +0100 (BST)

> ssthresh value that seems more reasonable.

Perhaps reasonable for the initial ssthresh, but only if some care is
taken I think.  With devices like HTTP load-balancers, and NAT, each
connection to a particular IP address could be to a different computer,
perhaps running a different OS or release.  So window sizes, MSS, number
of hops, use of timestamp/window-scale option etc could easily be quite
different for each connection to an IP address.  So some validation
would I think be needed to avoid picking up an implausible ssthresh for
the current window size.

	Richard
-- 
Richard Wendland				[email-masked]