[tcpm] TCP Error recovery and efficiency

Anthony Sabatini <tsabatini@hotmail.com> Mon, 09 July 2012 03:54 UTC

Message-ID: <BAY158-W52F89B5FC9355E00E9FE5FB0D30@phx.gbl>
Content-Type: multipart/alternative; boundary="_843d852d-c6c4-4172-8d30-a5024183b33b_"
From: Anthony Sabatini <tsabatini@hotmail.com>
To: tcpm@ietf.org
Date: Sun, 08 Jul 2012 23:55:09 -0400
Importance: Normal
MIME-Version: 1.0
Subject: [tcpm] TCP Error recovery and efficiency
Precedence: list

All -

While data communications was constantly improving, due mostly to the wide adoption of fiber optics, the fact that TCP had an inferior recovery mechanism was moot as it came into play less and less often.  Sadly those days are now behind us and we face a world increasingly hostile to data transmission.  The sources of packet loss have grown legion, "traffic shapers", congested links to the subscibers, overloaded wifi bands, content monitor that can not keep up, rate caps on mobile phone data usage, the list goes on and on.  Complicating this is the increase in data rates and file sizes which allow many more packets and their acknowledgements to be inflight between two endpoints at once.  We as a community must move along the proliferation of SACK and if we are going to do that we should fix the underlying issues in the protocol first.

All current TCP recovery implementations are based on guessing the state at the remote node.  No recovery mechanism currently in place gives sufficient weight to in-flight or delayed messages.  This problem can be solved easily by transmitting a token related to the transmission state in each out going message which the destination node will return on its next transmission.  By having this token I know all of the messages the far end should have seen and if I do not have an acknowledgement for any of them, I know that those need to be retransmitted.

To start this discussion I have created an I-D "Highly Efficient Selective Acknowledgement (SACK) for TCP" - draft-sabatini-tcp-sack-00 which I hope will be accepted by the working group.

Note that even though no TCP implementation exists, the HDLC version I created for the financial community has 20 years of working history all over the world and the capability for being 100% efficient right down to one error per message no matter what the data rate or the delay (including multiple satellite hops).

Tony

[tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Scheffenegger, Richard
Re: [tcpm] TCP Error recovery and efficiency (upd… Scheffenegger, Richard
Re: [tcpm] TCP Error recovery and efficiency Yuchung Cheng
Re: [tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency (upd… Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Joe Touch
Re: [tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Joe Touch
Re: [tcpm] TCP Error recovery and efficiency Matt Mathis
Re: [tcpm] TCP Error recovery and efficiency Anthony Sabatini
Re: [tcpm] TCP Error recovery and efficiency Scheffenegger, Richard