Subject: RE: An alternative to TCP (part 1)

From: Larry Foore <[email-masked]>
Date: Tue, 6 Feb 2001 17:04:51 -0500

>1. There are two annoying incompetence of TCP. One is that TCP does not
>   distinguish packet loss caused by network transmission error from that
>   caused by network congestion. The congestion control and avoidance
mechanism 
>   makes TCP drop its transmit window upon detecting a packet loss, thus
lowers
>   the transmit rate even if the loss is caused by physical link transmit
error.
>   This results in an unnecessary reduction in link bandwidth utilization, 
>   especially in the environment of wireless physical links.

Agreed.  This discontinuity allows room for NAT-like "fixes"  that don't
benefit the entire well being of the Internet as an entity.  This has been
seen with some of the limitations of PEPs (split connections more
specifically).  

I have explored such options for wireless systems.  The trade matrix looks a
lot like one for a NATed network -- good in the short term, questionable in
the long term.

>   The other is that the unit of TCP sequence number is byte (octet) while
the
>   the sequence number is only 32 bit wide. It is not a big problem for a
>   no-more-than-100Mbps network. But in a modern gigabit network, it takes
only
>   about 36 seconds to consume the whole sequence number space when
transmitting
>   at the maximum bit rate.

Is this really a problem?  How often would a single TCP session have
allocated to itself an entire gigabit link?  I'm not aware of any end
systems or apps that generate data at this rate (especially for any extended
length of time), much less accept it.  Maybe I'm looking at this wrong.

Respectfully,
-Larry

****************************************************************************
This message is intended only for the individual or entity to whom it is
addressed and may contain information that is privileged, confidential, and
exempt from disclosure under applicable law.  If you are not the intended
recipient, or the employee or agent responsible for delivering the message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited, and
you are requested to please notify us immediately by telephone at
(321-956-8846) and return the original message to the address above.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 6 Feb 2001 16:51:48 -0800

> length of time), much less accept it.  Maybe I'm looking at this wrong.

Just over too short a time window. 15 years ago the same was said for 2Mbps
rates when people started thinking about moving up to a whopping 45.  Think
10 years out and the question becomes 'who would be willing to settle for as
little as 1Gbps per connect?'

Tony

---

From: stanislav shalunov <[email-masked]>
Date: 06 Feb 2001 20:35:07 -0500

Larry Foore <[email-masked]> writes:

> How often would a single TCP session have allocated to itself an
> entire gigabit link?

At SC2000 there was an application (non-interlaced HDTV) using
1.5Gbps.

A web search brings up this:
http://ssadler.phy.bnl.gov/adler/sc2k/sc2kpg3.html

> This message is intended only for the individual or entity to whom
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law.  If
> you are not the intended recipient, or the employee or agent
> responsible for delivering the message to the intended recipient,
> you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited, and you are
> requested to please notify us immediately by telephone at

I guess I just violated that by quoting you.

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

"Nuclear war would really set back cable [television]."  -- Ted Turner

---

From: Colin Perkins <[email-masked]>
Date: Tue, 06 Feb 2001 23:21:25 -0500

>At SC2000 there was an application (non-interlaced HDTV) using

Sure, but it wasn't using TCP...  

Colin

---

From: Richard Carlson <[email-masked]>
Date: Wed, 07 Feb 2001 09:34:04 -0600

You're right, the TCP peak was 1.48Gbps from the show floor in Dallas to a 
storage cluster at Berkeley Laboratory.  Single applications using multiple 
stream.  Bottleneck link was 1.5Gbps provisioned circuit on Qwest link from 
convention center to DARPA's HSCC pop node.

This beat last years (SC'99) 1.2 Gbps rate Microsoft achieved running TTCP 
on a single PC with 2 Gbit Ethernet cards (Redmond to Portland).

Rich

---

From: Mahadevan Iyer <[email-masked]>
Date: Wed, 07 Feb 2001 16:23:03 -0800

> on a single PC with 2 Gbit Ethernet cards (Redmond to Portland).

Peak rate alone is a meaningless measure of performance. The TCP session may
have reached peak for a small fraction of the session duration and the rest of
the time, the link may have been severely under-utilized.
A meaningful performance measure here is average or percentile link utilization
over the tcp session duration.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 10:27:04 -0800

>Is this really a problem?  

Yes.

>How often would a single TCP session have allocated to itself an 

Think server-less backup on a Storage Area Network. 

>I'm not aware of any end systems or apps that generate data at this rate (
>especially for any extended length of time), much less accept it.  
>Maybe I'm looking at this wrong.

IP-based Storage Area Networks will generate data at this rate and higher.
We will have a 10 Gb Ethernet standard soon, and IP-based SAN vendors 
intend to be ready with NICs and storage systems that can run at that rate.
Furthermore, the IEEE tends to up Ethernet by an order of magnitude every
3 years or so. That means that by 2011 we should be planning for 
10,000 Gbps Ethernet. 

=================================================================
Thought for the day:

"This is no IP network. It's their love child, man" 
                  -- Dennis Hopper

---

From: Richard Carlson <[email-masked]>
Date: Wed, 07 Feb 2001 21:06:57 -0600

Right, peak rate doesn't tell the whole story.  The description of this 
project says:

262 Gbytes of data from LBL to SC2000 show floor
5 sec peak rate of 1.48 Gbps
60 min ave of 582 Mbps

see http://www-didc.lbl.gov/presentations/SC00.LBNL.netchallenge.pdf for 
more details.

Rich

>over the tcp session duration.

------------------------------------

Richard A. Carlson				e-mail: [email-masked]
Network Research Section			phone:  (630) 252-7289
Argonne National Laboratory			fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439