Subject: RE: [Tsvwg] Re: HighSpeed TCP for Large Congestion Windows

From: [email-masked]
Date: Wed, 21 Aug 2002 16:33:31 -0400

Reiner,

> Such applications would have to move *terra* bytes *back-to-back* to start

> having that problem. I'm not convinced that such applications are running 
> on the *public* Internet today or in the foreseeable future. Please, 
> convince me if you think otherwise.

I think you doth protest a bit much.  *giga* bytes should be more than
adequate to get into the area where these effects start to become real.

> Even if members of the IP Storage WG are talking about moving large pieces

> of data, are they really moving *terra* bytes *back-to-back*? Sending only

> a few 10 Gigabytes every now and then is a different story.

Storage traffic is not "every now and then" - for a concrete example, pull
all the disk drive(s) out of the system on which you're reading this email
and see how long the OS stays up :-).  Storage traffic on a fast link is
measured in megabytes per second - usually 2 or 3 digits of MB/sec, and
runs more or less continuously.  It doesn't take very long running at that
sort of rate to generate gigabytes.

A separate issue is what the RTTs will be.  Between a computer and its
disks, these have to be small - a good rule of thumb is that if the
latency is more than a few milliseconds, performance problems will occur.
So, one has to look elsewhere to generate the large RTT x BW products that
open enormous windows.  There are two places to look:
- Asynchronous Replication.  In a large installation, this can involve
	replication of the entire contents of multiple multi-terabyte
	storage arrays across large distances on a continuous basis.
- Geographic Backup.  For a large installation, the required backup
	rates can be measured in terabytes/hour, and there are people
	interested in having the disk storage and the backup tape drives/
	libraries separated by some serious geography.
At the moment, all of the IP Storage protocols can spread their traffic
across multiple TCP connections, and hence can keep congestion windows
down in that fashion, but we'd like to have the opportunity to use fewer
TCP connections to get the job done in a simpler fashion.

Thanks,
--David (co-chair IP Storage WG).
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Arun Prasad <[email-masked]>
Date: Thu, 22 Aug 2002 16:29:40 +0100

Hi all,
From draft "draft-stewart-tsvwg-sctpipv6-01.txt" Sec 3:
     The receiver of an INIT will identify the relevant zone by the
    scope of the source address and the arrival interface. In
    choosing addresses to place in the INIT-ACK the following
    considerations apply:

    - the receiver of the INIT will use the locally-significant
      "zone identifier" [scoped-addr-arch] to scope the addresses
      listed in the INIT-ACK.

    Can anyone explain this in simple terms....  How can the receiver of the INIT
chunk will get the "locally significant Zone Identifier"... If we receive the SCTP
packet with the recvmsg call, then we get the structure in6_pktinfo, which has the
ipv6 address and "ipi6_ifindex"... Should we take the ipi6_ifindex as the
identifiier here....
Really confusing....

Thanks
-arun

--
****************************************************************
V.ARUN PRASAD
HCL Technologies Ltd.,
Networking Technologies Lab,
Ground Floor, Block - 1, Chandamama Building,
184 to 188,190,192 & 196, NSK Road,
Vadapalani,
Chennai - 600 026

Phone: Off: +91-44-3728366/67/69, +91-44-3728156/57 Extn. 1133
Fax: +91-44-4806640
****************************************************************

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Aug 2002 09:01:15 -0700

> adequate to get into the area where these effects start to become real.

As you observe later, it's BW*delay that is the issue.

Well, at least one issue. The other issue is whether such traffic needs 
to be done in a protocol modified in a public forum.

> 	libraries separated by some serious geography.

In both of these cases, much of the traffic is across dedicated links. 
In those cases, TCP can be modified and used over those links without 
affecting the rest of the Internet.

> TCP connections to get the job done in a simpler fashion.

Using multiple connections is just cheating, congestion-wise. See RFC-2140.

Joe