Subject: [Tsvwg] Next Generation TCP/IP Technology : Instant Guaranteed Service TCP Technology

From: [email-masked]
Date: Fri, 5 Mar 2004 12:51:44 EST

Instant Guaranteed Service TCP Technology

pls see http://www.prweb.com/releases/2003/10/prweb82050.php 

AN INDEPENDENT WORLD'S TOP MOST TCP/IP EXPERT ASSESSMENT OF THETECHNOLOGY :

This is my initial Technology Report on the Instant Guaranteed ServiceTCP 
Technology , 8 patent numbers starting GB0312203.3 most recent GB0330114.0       
filed       between  28 May 2003  and   29 Dec 2003. Commercial ready software 
is currently being developed,tests results data sets derived therein will be  
collected to confirmand/or enhance the contents of this Report.

Dated this 12 January 2004

Instant Guaranteed ServiceTCP Technology (IGSTT)IGSTT is an interesting and 
promising technology.  Actual resultssubject to confirmation through testing.  
Prototypes and commercial software currently is already partly completed.

TCP is an evolutionary technology.  Most implementations have been updated as 
new ideas surface, including John Nagle's algorithm for reducing congestion, 
Phil Karn's algorithm and Van Jacobson's many contributions.These innovations 
took TCP in new directions.  Previously it was generally assumed that TCP was 
a slow protocol, sacrificing performance for loftier goals such as broad 
compatibility across platforms, and ability to scale over WANs.  However, after 
these changes, TCP was found to perform far beyond its conservative rootsand it 
handily displaced other popular (or in the case of OSI,unpopular) protocols.

Now that performance is well established, making file transfer speedsquite 
impressive, the new holy grail of the internet is multimedia performance.  
Everything from IP telephony to video conferencing andmovie downloads all depend on 
data being delivered within a perceptiontolerance period; meaning human 
listeners and viewers do not perceive a problem despite real world network 
delivery.

Much progress has been made with Quality of Service (QoS) features are now 
available on most networking hardware and protocols such as RFC1889 RTP (Real 
Time Protocol) which aim to provide the fundamental time critical data delivery 
necessary for audio and video. However,QoS requires end-to-end implementation 
to be effective, and the reality of multi-vendor LAN and WAN connectivity make 
this challenging to achieve.

The IGSTT proposed protocol enhancements for TCP have a goal of achieving 
guaranteed service delivery for both raw data downloads andreal time data, bypass 
QoS entirely.  To be effective, one must either upgrade all computers at the 
site, or use a NAT-like concentrator to inject the technology between WAN 
links.

With IGSTT, real time data will have  timely delivery if raw filetransfers 
(such as HTTP) are not clogging up the router's buffers, and this is possible if 
all TCP implementations competing forthe bandwidth are sensitive to their 
sessions; bounded roundtrip times  thereby avoiding overfull router and switch 
buffers. Under this system, TCP transmitters would very responsively throttle 
back the very moment the network starts to become congested, and this will allow 
rapid congestion recovery and free the network from further congestion Under 
IGSTT, the response time in throttling the transmission rate is built into TCP 
itself.

His system easily interoperates with every existing TCP.  Of course,immediate 
wide spread adoption on the Internet seems unrealistic, but it is not 
actually fully necessary.  Using tunnelling, such as is performed by NAT (Network 
Address Translation) implementations, only the tunnelling pairs would need to 
implement the changes.  The diagram below depicts such a configuration which 
would use his modifications in the network core between the two tunnel ends over 
the Internet.

real client  -- tunnel end A -  tunnel end B -- real server

If tunnelling is employed at the ISP or the client site's external router, 
then traffic shaping can be instituted, even against the greedy wishes of a 
client computer.

The choice of packet for determining round trip time calculation canbe 
difficult.  Phil Karn's research reminds us that TCP ACKs of retransmitted packets 
cannot be used for RTO calculation because theACK could be for the initial or 
the retransmitted packet.  IGSTT strategy is to use the (_______).

It appears that the technology can deliver perception tolerance audioand 
video (subject to testing currently in progress), and tunnelling technologies are 
used to enable rapid deployment, this technologywould prove extremely 
lucrative to the ISP market, corporate privatenetwork, and IGSTT technology resellers.

PLEASE NOTE : While the author believes to be true the contentscontained in 
this report  herein, no liability in any form whatsoever could be construed as 
arising in anyway whatsoever  nor attributable relating to the use of the 
material herein.

(_____________)
(_____________) * note : we provide this only to researchers group interested 
in technology collaborations with us * 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++

SUMMARY :+ characteristics : all packets (both raw data & audio-visual) 
arrive within perception tolerance time period from source to destination 
onInternet.

+ possibly not a single packets (both raw data & audio-visual) ever gets 
dropped

Research groups interested in technology collaborations please email us

+ email us with brief introductions of your group, for detailed step by step 
instructions to be sent to test & confirm independently DIY : essentially just 
a few very simple lines of Linux TCP open source code modifications 

CONTACT
IWXChange Inc
http://iwxchange.com
EMail : [email-masked]

---

From: Sam Liang <[email-masked]>
Date: Fri, 5 Mar 2004 13:01:44 -0800

I am not sure exactly what this IGSTT does. There is not any technical
detail revealed. If it's patented, it is disclosable, right?

  Without understanding what it does, it's hard to believe it can achieve
what claims to. It sounds like it relies on competing TCP flows to
backoff more quickly. How? Also does the real-time flow using IGSTT do
congestion control on itself? 

  How can it "Gurantee" no packet loss, if routers and switches may drop
packets?

  What does "Instant" mean? How fast is instant? If there is a packet drop
in the network, does it do restransmission?

Sam

> arising in anyway whatsoever  nor attributable relating to the use of the 

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