Subject: [tcpm] proposal to update & obsolete RFC 793

From: Wesley Eddy <[email-masked]>
Date: Tue, 22 Oct 2013 00:35:33 -0400

After some prior threads mentioning that at least a few people
think it would be desirable to have an updated and somewhat more
consolidated TCP specification, Andre Oppermann and I have been
outlining what we think this might look like and what would need
to be included.

As the draft submission cutoff approached, we aren't as far as
hoped for, but a sketch of what we are thinking is at:
http://www.ietf.org/id/draft-eddy-rfc793bis-00.txt

I would like to start talking about this on the list and at the
meeting in Vancouver to understand if people would be supportive
of this, and whether the proposed scoping of what to include or
not include sounds sane.

-- 
Wes Eddy
MTI Systems

---

From: Andre Oppermann <[email-masked]>
Date: Tue, 22 Oct 2013 08:55:56 +0200

> of this, and whether the proposed scoping of what to include or

The idea for rfc793bis clearly is to consolidate the current state
of an fully updated rfc793 to make it much easier to a) check an
existing implementation for conformance; b) write a new implementation
from scratch.  Based on my experience of working on the FreeBSD TCP
stack and having recently coached one developer for the latter I
believe I've got a good feeling where the current stack of RFCs falls
short.

Again rfc793bis should not introduce any new concepts but consolidate
and roll up the current stack of RFC's into a single document that is
written in a modern style with TCP implementors in mind.  All the
concepts of TCP will be included but for example congestion control
algorithms as such won't be part of it in remain in their current
rfc series because they are constantly evolving.

-- 
Andre

---

From: David Borman <[email-masked]>
Date: Tue, 22 Oct 2013 12:52:55 +0000

On Oct 22, 2013, at 1:55 AM, Andre Oppermann <[email-masked]> wrote:
...
> rfc series because they are constantly evolving.

I fully agree.  The draft document further implies that the scope is limited to things that have been previously published in other RFCs, plus errata; that will make it much easier to make progress.

It might be useful to have a section for what *isn't* being incorporated, and why.  There are two parts to that, 1) items that are not recommended, and 2) companion documents that are relevant to TCP, such as congestion control.

Also, to the extent that the previous RFCs contain the justifications for particular changes that are being incorporated, I wouldn't try to pull that all into this document.  For example, RFC 6691 (MSS) has way too much explanation and justification to incorporate into 793bis.  For deciding whether or not to include explanations, one litmus test would be "does this additional information help someone trying to implement TCP?"

Another item to add to the todo list:
	2675 IPv6 Jumbograms

		-David Borman

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

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 22 Oct 2013 13:06:56 +0000

Hi David, Wes, Andre, and *

just came into my mind... If we incorporate an RFC into RFC793bis completely - let say RFC 6691 (MSS) or
RFC 6093 (urgent pointer) - do we obsolete with RFC793bis the incorporated one too?

Alex

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 22 Oct 2013 09:16:09 -0400

> RFC 6093 (urgent pointer) - do we obsolete with RFC793bis the incorporated one too?

My inclination is to obsolete anything that winds up fully
incorporated in terms of normative protocol changes that
were made, but retain an informational reference to the old
RFC so that someone can easily reach the rationale and other
discussion which we wouldn't try to replicate.

-- 
Wes Eddy
MTI Systems

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 22 Oct 2013 13:18:03 +0000

OK, make sense. +1

Alex

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 22 Oct 2013 16:23:09 -0700

> rfc series because they are constantly evolving.

Sounds wonderful!  I presume that the layout of all known TCP options
(including timestamps and SACK) will be defined, but the mechanics
(which timestamp to send, how to react to SACKs) will be defined by
existing (or future) separate RFCs?

I'd love to have an all-singing, all-dancing draft with SACK and
all the rest folded into it, but that does sound like quite a bit
more work.  And all of that is far more likely to change over time.

Thanks for taking this on!

Kevin
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Oct 2013 17:11:20 -0700

FWIW, it might be useful to learn from HTTP here.

1.1 is a monster of a doc largely because it is all-inclusive.

It might be preferable to have separate docs:

	- core TCP
		mostly current 793, with updates/corrections
		and required options
	- congestion control
	- "optional options" (bells and whistles)

Joe

---

From: Kevin Mason <[email-masked]>
Date: Tue, 22 Oct 2013 20:15:51 -0400

Good point, it would make it much easier to comprehend and discriminate what is required and what is optional.

Kevin

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 22 Oct 2013 22:00:45 -0700

On Oct 22, 2013, at 8:26 PM, Varghese, Reji wrote:

> That's a good thought, Joe.
> 
> - core protocol could be what all implementations can (or mandatorily) conform to and basic compliance can be validated to
> - other enhancements (like, congestion control) could be additional implementations. An implementation that does not have these enhancements may necessarily not be non-compliant

Sure, congestion control should be in a different document, but what I find very annoying as an engineer actively working on a TCP stack is precisely the requirement to integrate a bazillion documents -- "No, no, wait, this is where we need to handle timestamps!" or, "Oh, yeah, we need to do a SACK check here," or "Oh, yeah, we gotta cryptographically generate an ISN here."[*]  It's frustrating to have to reference multiple RFCs to track what's going on in the code, and it would be really nice to have it all in one place.

As I said, that would obviously make for a book-sized RFC.  I understand that isn't going to happen.  But it sure would be nice to have call outs in various places to the appropriate documents, rather than trying to keep track of a few dozen RFCs in my head.  I will certainly try to contribute where I can.

Thanks,

Kevin
[email-masked]

[*] And the I-D seems to recognize this.

---

From: "Varghese, Reji" <[email-masked]>
Date: Wed, 23 Oct 2013 03:26:51 +0000

Regards
Reji Varghese

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: 23 October 2013 05:41 AM
To: Kevin Lahey
Cc: [email-masked]
Subject: Re: [tcpm] proposal to update & obsolete RFC 793

	- core TCP

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Oct 2013 08:21:24 -0700

FWIW, I was thinking more of a very small set of docs, each with a 
specific focus. I agree having dozens of docs isn't useful, but we 
should all admit that this "one shot" revision isn't going to solve 
anything long term, because we'll continue to have updates anyway.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 23 Oct 2013 09:02:43 -0700

On Wed, Oct 23, 2013 at 8:21 AM, Joe Touch <[email-masked]> wrote:
>
> FWIW, I was thinking more of a very small set of docs, each with a specific focus. I agree having dozens of docs isn't useful, but we should all admit that this "one shot" revision isn't going to solve anything long term, because we'll continue to have updates anyway.

I can't agree more.

As a TCP implementer who works on the Linux stack that "sort of"
supports literally dozens of RFCs, IMO it's very hard O(n^2) to merge
RFCs b/c a lot of them are simply not compatible. Subtle interaction
details can only be discovered and addressed in actual implementations
and real networks. Many RFCs are written based on a simple stack runs
AIMD + sack w/o real implementation.

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 23 Oct 2013 19:24:33 +0200

On 23.10.2013 17:21, Joe Touch wrote:
> FWIW, I was thinking more of a very small set of docs, each with a specific focus. I agree having
> dozens of docs isn't useful, but we should all admit that this "one shot" revision isn't going to
> solve anything long term, because we'll continue to have updates anyway.

The purpose of rfc723bis is to roll up and integrate the core TCP specifications
into an easily digestable format.  So it will cover the wire format, the state
machine, the sequence number system, segment acceptance, ACK clock and window
system among others.  Also widely deployed options like window scaling and SACK
will show up with their wire format and behavior.  Neither congestion control nor
loss recovery algorithms will be covered in any specific form, only their general
purpose and necessity will be clearly explained.  Appropriate and clear references
to the currently accepted congestion control and loss recovery algorithms will be
made with idea of having them evolve independently from the wire format and core
mechanics specification.

RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323, 1981, 2018,
2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961, 6093, 6528, 6633, 6691.
I may have forgotten about one or the other though.  Please don't take this list
as final.

A prospective implementor should be able to write an interoperable and standards
compliant implementation with only rfc793bis and 6582 for example for congestion
control.

There will always be the advanced features and algorithms RFCs which may or
may not conflict in one way or the other.  Dealing with them is out of scope
for rfc793bis.  However everyone is invited to start an effort in that area
as well.

-- 
Andre

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Oct 2013 10:30:45 -0700

On 10/23/2013 10:24 AM, Andre Oppermann wrote:
> The purpose of rfc723bis is to roll up and integrate the core TCP
> specifications into an easily digestable format. So it will cover the
> wire format, the state machine, the sequence number system, segment
> acceptance, ACK clock and window system among others.

That makes sense.

 > Also widely
> deployed options like window scaling and SACK will show up with their
> wire format and behavior.

I think that is a mistake. The core document should describe the 
required components only.

> Neither congestion control nor loss
> recovery algorithms will be covered in any specific form, only their
> general purpose and necessity will be clearly explained. Appropriate
> and clear references to the currently accepted congestion control and
> loss recovery algorithms will be made with idea of having them evolve
> independently from the wire format and core mechanics specification.

Agreed.

> RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323,
> 1981, 2018, 2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961,
> 6093, 6528, 6633, 6691. I may have forgotten about one or the other
> though. Please don't take this list as final.
>
> A prospective implementor should be able to write an interoperable
> and standards compliant implementation with only rfc793bis and 6582
> for example for congestion control.

That makes sense to me, but the popularity or prevalence of various 
features is not the issue; their necessity is.

Joe

> may not conflict in one way or the other. Dealing with them is out
> of scope for rfc793bis. However everyone is invited to start an
> effort in that area as well.

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 23 Oct 2013 22:36:30 +0200

On 23.10.2013 19:30, Joe Touch wrote:
> I think that is a mistake. The core document should describe the required components only.

Well, to avoid splintering into lots of additional documents I believe
the rfc793bis should include widely implemented options too, like SACK
describing the wire-format and loss/out-of-order ACK behavior.
However it remains an optional part of specification and will refer to
other loss recovery documents describing how to actually make good use
of the additional information on the sender.

It may read something like this: "A TCP speaker SHOULD implement SACK
to improve the senders loss recovery information.  If it implements it,
it MUST be done ... [as in RFC2018]".

Lets quickly go through it:

NOP (mandatory)
EOL (mandatory)
MSS (mandatory)
WSCALE (SHOULD, optional)
SACK (SHOULD, optional)
TS (MAY, optional, refer to RFCxxx for timestamp reflection logic)
SIGNATURE (MAY, optional, refer to RFCxxx for details)
AO (MAY, optional, refer to RFCxxx for details)
ECN (MAY, optional, [not really a tcp option])

> That makes sense to me, but the popularity or prevalence of various features is not the issue; their
> necessity is.

With high BDPs certain options like SACK are pretty much a necessity
to actually get any reasonable bandwidth/goodput out of it.

-- 
Andre

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Oct 2013 14:39:08 -0700

> describing the wire-format and loss/out-of-order ACK behavior.

But this is the problem. "Widely implemented" depends on context - 
features widely deployed in cloud systems are not necessarily used in 
home computers, those in home computers not in sensors.

IMO, if it's not mandatory, it needs to be outside the core doc.

> to actually get any reasonable bandwidth/goodput out of it.

That's a performance issue, not a correctness issue.

Joe

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 24 Oct 2013 13:46:05 -0400

With respect to Joe Touch's comments, as they would say in the Supreme Court, I concur in part and I dissent in part.

RDF 793 is a wonderful document in that it provides a framework on which a much better protocol than the one defined in the document can be built.  The key to TCPs longevity and X.25's demise is that ability to grow and change, X.25 being so over specified that there was no room for growth and change to accommodate future needs and it was ignored as a result.

The complaint really is that there is no "document of documents" available, a document describing the existing extensions, how they interact and what problems they solve.  793bis SHOULD NOT be that vehicle.  We live in a modern, connected age, living documents are possile and the IETF should learn how to create and use them.

The ONLY thing that should be in 793bis is that which is cast in concrete, the three items labeled "mandatory" on the list Joe references, all else should be in a "recommended practices" document, tthe document of documents.  If TCP is to survive it must grow and anytime you define an absolute, even loosely like SACK or TS, you limit that growth, no matter how well intentioned, and start the process where TCP strangles itself.

Directly to that point see my protocol submission to TCPM on Monday.

Tony

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

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

> Date: Wed, 23 Oct 2013 14:39:08 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Oct 2013 10:55:13 -0700

On 10/24/2013 10:46 AM, Anthony Sabatini wrote:
> With respect to Joe Touch's comments, as they would say in the Supreme
> Court, I concur in part and I dissent in part.
>
> RDF 793 is a wonderful document in that it provides a framework on which
> a much better protocol than the one defined in the document can be
> built.  The key to TCPs longevity and X.25's demise is that ability to
> grow and change, X.25 being so over specified that there was no room for
> growth and change to accommodate future needs and it was ignored as a
> result.
>
> The complaint really is that there is no "document of documents"
> available, a document describing the existing extensions, how they
> interact and what problems they solve.

RFC 4614?

Joe

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 24 Oct 2013 14:11:43 -0400

Fabulous point and fabulous start, Joe.

RFC 4614 has just turned seven years old, lets send it off to second grade and have a new baby.  By the time the pregnancy of 4614bis is done RFC 4614 will be eight years old.

I would recommend a slightly more enlightened approach, first half of documents should cover items that are "SHOULD" (SACK, TS) and the second half should cover "MAY".

I also think that it should be self obsoleting, requiring update in five years to maintain relevancy.

Tony

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

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

> Date: Thu, 24 Oct 2013 10:55:13 -0700
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Oct 2013 11:21:34 -0700

On 10/24/2013 11:11 AM, Anthony Sabatini wrote:
> RFC 4614 has just turned seven years old, lets send it off to second
> grade and have a new baby.  By the time the pregnancy of 4614bis is done
> RFC 4614 will be eight years old.

I thought part of this discussion began with the fact that 4614-bis is 
underway, and that this wasn't considered sufficient.

> I would recommend a slightly more enlightened approach, first half of
> documents should cover items that are "SHOULD" (SACK, TS) and the second
> half should cover "MAY".

Oh, I misunderstood your point.

IMO, there are only two classes of docs:

	MUST

	others

That's the difference between correctness and performance. Anything 
outside a MUST is an option, depending on context.

> years to maintain relevancy.

That might be said of many RFCs in general, but I also feel anything 
that isn't useful in 10 years isn't worth writing.

Joe

---

From: Anthony Sabatini <[email-masked]>
Date: Thu, 24 Oct 2013 14:44:38 -0400

Joe -

Again I must find I agree with you on most points.  Also in my humble opinion anything not labeled "MUST" should be left out of the primary RFC and relegated to it's own RFC.

Where we differ is on the 10 year issue.  We are about to loose all of the original knowledge about these protocols as the first generation of researchers and implementers leave the playing field (other than myself I am unaware of anyone who worked with the original IMP protocol that preceded TCP).  Those that replace the first generation are from radically different countries, cultures and education and we need to be mindful that they must recreate in their own minds all of the technology which came before so that they may go beyond it, and these documents must be regularly updated since new people enter the field every day.  Documents like 4614 provide that insight and roadmap as to how to approach such knowledge and are thus extaordinarily valuable to those who will eventually inherit the IETF.

Tony

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

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

> Date: Thu, 24 Oct 2013 11:21:34 -0700
> From: [email-masked]

---

From: <[email-masked]>
Date: Fri, 25 Oct 2013 07:05:00 +0100

4614bis?

I'm still waiting on 1323bis.

Which, if you compare:
http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-15
and
http://www.kohala.com/start/tcplw-extensions.txt

has now taken OVER TWENTY YEARS TO GET PUBLISHED.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Anthony Sabatini [[email-masked]]
Sent: 24 October 2013 19:11
To: Joe Touch; [email-masked]
Cc: tcpm
Subject: Re: [tcpm] proposal to update & obsolete RFC 793

Tony

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

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