Subject: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds"

From: Carsten Bormann <[email-masked]>
Date: Thu, 31 Jan 2013 17:42:06 +0100

(Off-topic...)

Just got pointed to this at $DAYJOB.
All snake-oil alarms go off just from the buzzwords, so I didn't look at it in detail.
But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in the process (30x throughput!).
They even seem to have put in a PEP.

If anyone happens to analyze this and can translate from PR speak to something someone on this list would understand, please do post a pointer to your praise/scorcher here.  Otherwise we return you to your regular program...

http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html

Grüße, Carsten

PS.: Is it just me or are these getting more frequent recently?

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 31 Jan 2013 17:08:11 +0000

Hi,

my guess would be that they introduce a non-realistic amount of random (non-congestion) loss in their simulation to make TCP loo real bad. Their own solution probably employs some mechanism that doesn't ramp down when such loss happens. And I'd guess that fairness isn't a concern either.

Lars

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 31 Jan 2013 17:39:47 +0000

Some interesting comments on it here:)

http://forums.theregister.co.uk/forum/1/2013/01/30/fujitsu_speedy_data_transfer_protocol/#c_1710380

I didn't write any of those comments but found some pretty spot on your mileage may vary.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] on behalf of Carsten Bormann [[email-masked]]
Sent: Thursday, January 31, 2013 9:42 AM
To: [email-masked] list
Subject: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds"

(Off-topic...)

Grüße, Carsten

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 31 Jan 2013 18:42:43 +0100

Do we need an RFC that explains to the press, in very simple language, some very basic tests that a TCP marketing text should pass before publishing it on whatever IT news site?

Well, probably even that would not help :(

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eggert, Lars
> Sent: Thursday, January 31, 2013 6:08 PM
> To: Carsten Bormann
> Cc: [email-masked] list
> Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer 
> Protocol Enabling Improved Transmissions Speeds"
> 
> Hi,
> 
> my guess would be that they introduce a non-realistic amount 
> of random (non-congestion) loss in their simulation to make 
> TCP loo real bad. Their own solution probably employs some 
> mechanism that doesn't ramp down when such loss happens. And 
> I'd guess that fairness isn't a concern either.
> 
> Lars
> 
> > But maybe they have solved bufferbloat (1/6 latency!) and 
> fixed CC in the process (30x throughput!).
> > If anyone happens to analyze this and can translate from PR 
> speak to something someone on this list would understand, 
> please do post a pointer to your praise/scorcher here.  
> Otherwise we return you to your regular program...
> > 
> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jan 2013 09:53:04 -0800

Not that new. There were several companies in the mid-90's that did TCP 
accelerators - by basically ignoring CC.

They pop up every few years. Then people tend to realize they want 
reliable, universal access, and that most of the time TCP is already 
"optimized" for that; other optimizations tend to come at an expense..

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jan 2013 09:55:04 -0800

> Do we need an RFC that explains to the press, in very simple language, some very basic tests that a TCP marketing text should pass before publishing it on whatever IT news site?

Right after we write one that explains that the press ought to consider 
it their job to investigate, not just act as a marketing channel...

(good luck with that - most news divisions are now placed under the 
direction of "entertainment" or "marketing" divisions now)

Joe

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 31 Jan 2013 14:01:16 -0500

All -

Well now you all know what I have been talking about fotr the last year.  Fujitsu has rediscovered the protocol and techniques I used in creating TDLC thirty years ago.  If you want to know how it works, see my submital to IETF 'TDLC, An improved "Selective Repeat" protocol' draft-sabatini-tdlc-00, or mail me and I will send you a copy.

And yes, it is that good, never re-sending a message that was received, near 100% effective bandwidth utilization, automatically adjusts to link availability IN REAL TIME.  Yes it is real and you can ALMOST make TCP-IP that good, the problem with TCP-IP is supporting bad legacy decisions.

Tony

Anthony Sabatini
200 West 20th Street
Apt. 1216
New York, NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Thu, 31 Jan 2013 18:42:43 +0100
> CC: [email-masked]
> Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer	Protocol	Enabling	Improved Transmissions Speeds"
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 31 Jan 2013 20:26:07 +0100

For what it is worth, two of the very basic questions in my proposed RFC would be:

* Can you find the word "Selective Acknowledgments" or the abbreviation "SACK" in the marketing text? (Footnote: Please also check for the spelling "Selective Acknowledgements", and for singular form.)

* Can you find the word "measurement" in the marketing text? Ideally in one sentence with terms such as "Windows", "Linux", "OS X", "BSD"? 

But, sigh, maybe the challenge is indeed too large.

Michael

PS: I also might have forgotten some irony tags somewhere.

> From: Anthony Sabatini [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2013 8:01 PM
> To: Scharf, Michael (Michael); [email-masked]; [email-masked]
> Cc: tcpm
> Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer 
> Well now you all know what I have been talking about fotr the 
> last year.  Fujitsu has rediscovered the protocol and 
> techniques I used in creating TDLC thirty years ago.  If you 
> want to know how it works, see my submital to IETF 'TDLC, An 
> improved "Selective Repeat" protocol' draft-sabatini-tdlc-00, 
> or mail me and I will send you a copy.
> 
> And yes, it is that good, never re-sending a message that was 
> received, near 100% effective bandwidth utilization, 
> automatically adjusts to link availability IN REAL TIME.  Yes 
> it is real and you can ALMOST make TCP-IP that good, the 
> problem with TCP-IP is supporting bad legacy decisions.
> 
> Tony
> 
> 
> Anthony Sabatini
> 200 West 20th Street
> Apt. 1216
> New York, NY 10011
> 
> Phone: (212) 867-7179
> Mobile: (917) 224-8388
> 
>  
> 
> 
> 
> > Do we need an RFC that explains to the press, in very 
> simple language, some very basic tests that a TCP marketing 
> text should pass before publishing it on whatever IT news site?
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Eggert, Lars
> > > my guess would be that they introduce a non-realistic amount of 
> > > random (non-congestion) loss in their simulation to make TCP loo 
> > > real bad. Their own solution probably employs some mechanism that 
> > > doesn't ramp down when such loss happens. And I'd guess that 
> > > fairness isn't a concern either.
> > > 
> > > Lars
> > > 
> please do 
> > > post a pointer to your praise/scorcher here.

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 31 Jan 2013 14:34:04 -0500

Michael -

You will never see the words SACK or selective acknowledgement any where near any of these classes of protocol.  These protocols recreate the receiving stations state at the sending station and therefore what is validly missing (and must be repeated) are most important, not what was received.  It is the receiver which must control the transmitter, a basic oversight in how TCP-IP looks at the world.

Tony

Anthony Sabatini
200 West 20th Street
Apt. 1216
New York, NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388

> To: [email-masked]; [email-masked]; [email-masked]
> CC: [email-masked]
> Date: Thu, 31 Jan 2013 20:26:07 +0100
> Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds"
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 31 Jan 2013 20:43:17 +0100

Well, if a marketing texts includes the term "SACK", there is maybe a slightly higher change that the observed 1000% performance improvement "over TCP" is achieved at least against at a reasonable baseline.

Michael

> Sent: Thursday, January 31, 2013 8:34 PM
> You will never see the words SACK or selective 
> acknowledgement any where near any of these classes of 
> protocol.  These protocols recreate the receiving stations 
> state at the sending station and therefore what is validly 
> missing (and must be repeated) are most important, not what 
> was received.  It is the receiver which must control the 
> transmitter, a basic oversight in how TCP-IP looks at the world.
> 
> Tony
> 
> Anthony Sabatini
> 200 West 20th Street
> Apt. 1216
> New York, NY 10011
> 
> Phone: (212) 867-7179
> Mobile: (917) 224-8388
> 
>  
> 
> 
> 
> > * Can you find the word "Selective Acknowledgments" or the 
> > abbreviation "SACK" in the marketing text? (Footnote: Please also 
> > check for the spelling "Selective Acknowledgements", and 
> for singular 
> > form.)
> > 
> > * Can you find the word "measurement" in the marketing 
> text? Ideally in one sentence with terms such as "Windows", 
> "Linux", "OS X", "BSD"? 
> > 
> > > Well now you all know what I have been talking about fotr 
> the last 
> > > year. Fujitsu has rediscovered the protocol and 
> techniques I used in 
> > > creating TDLC thirty years ago. If you want to know how it works, 
> > > see my submital to IETF 'TDLC, An improved "Selective Repeat" 
> > > protocol' draft-sabatini-tdlc-00, or mail me and I will 
> send you a 
> > > copy.
> > > 
> automatically 
> > > adjusts to link availability IN REAL TIME. Yes it is real and you 
> > > can ALMOST make TCP-IP that good, the problem with TCP-IP is 
> > > supporting bad legacy decisions.
> > > 
> > > Tony
> > > 
> > > 
> > > Anthony Sabatini
> > > 200 West 20th Street
> > > Apt. 1216
> > > New York, NY 10011
> > > 
> > > Phone: (212) 867-7179
> > > Mobile: (917) 224-8388
> > > 
> > > 
> > > 
> > > 
> > > 
> > > simple language, some very basic tests that a TCP marketing text 
> > > should pass before publishing it on whatever IT news site?
> > > > 
> > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data 
> Transfer Protocol 
> > > > > Enabling Improved Transmissions Speeds"
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > real bad. Their own solution probably employs some mechanism 
> > > > > that doesn't ramp down when such loss happens. And I'd guess 
> > > > > that fairness isn't a concern either.
> > > > > 
> > > > > Lars
> > > > >

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 31 Jan 2013 14:53:18 -0500

Michael -

Theoretical SACK is not PRACTICAL SACK - SACK is effectively disabled in a high congestion or high error rate environment (a fact I have made comment on repeatedly).

The Fujitsu or TDLC protocol IS NOT SUSCEPTIBLE to congestion collapse.  SACK as currently defined is, SACK with my recommended changes is not. The obsession wit Reno. Vegas, Tahoe et seq. IS THE PROBLEM not a cure, SACK is an affirmative fix but is effectively neutered by legacy recovery myths.

Tony

Anthony Sabatini
200 West 20th Street
Apt. 1216
New York, NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388

> Date: Thu, 31 Jan 2013 20:43:17 +0100

---

From: <[email-masked]>
Date: Fri, 1 Feb 2013 06:19:39 +0000

Hmmm, Saratoga uses the same ideas as TDLC, although we went for index pairs rather than the bitmap. Confirmed and Highest Received are in there, as is the capability for RTT measurement.

TCP SACK is constrained by existing TCP option space.

Congestion control is needed when sharing, but when you own and run a dedicated private link you can simplify and engineer for throughput. Using Internet technology doesn't mean you're on the shared Internet.

Lloyd Wood
http://saratoga.sf.net/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Anthony Sabatini [[email-masked]]
Sent: 31 January 2013 19:01
To: tcpm Michael Scharf; [email-masked]; [email-masked]
Cc: tcpm
Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds"

All -

Tony

Anthony Sabatini
200 West 20th Street
Apt. 1216
New York, NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388