Subject: [tcpm] Roadmap for TCP - New Version

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 01 Apr 2013 20:13:27 +0200

Hi Group,

today I finally submit a new version of the TCP roadmap. Sorry for the long
delay :-) I include all new RFCs up to the new RFC 6897. Based on a email from
Wes I also include all old, forgotten RFC into the roadmap (*).

Moreover I change a little bit the structure of the doc. Basically, I
introduce some new sections and subsections so that the reader can find more
easily the RFCs in question. The new structure is fully aligned with RFC 5783
(Congestion Control in the RFC Series).

Happy for feedback
Alex

---

A new version of I-D, draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt
has been successfully submitted by Alexander Zimmermann and posted to the
IETF repository.

Filename:	 draft-zimmermann-tcpm-tcp-rfc4614bis
Revision:	 01
Title:		 A Roadmap for Transmission Control Protocol (TCP) Specification Documents
Creation date:	 2013-04-01
Group:		 Individual Submission
Number of pages: 46
URL:             http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt
Status:          http://datatracker.ietf.org/doc/draft-zimmermann-tcpm-tcp-rfc4614bis
Htmlized:        http://tools.ietf.org/html/draft-zimmermann-tcpm-tcp-rfc4614bis-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-zimmermann-tcpm-tcp-rfc4614bis-01

Abstract:
  This document contains a "roadmap" to the Requests for Comments (RFC)
  documents relating to the Internet's Transmission Control Protocol
  (TCP).  This roadmap provides a brief summary of the documents
  defining TCP and various TCP extensions that have accumulated in the
  RFC series.  This serves as a guide and quick reference for both TCP
  implementers and other parties who desire information contained in
  the TCP-related RFCs.

---

(*)

RFC 1191 - Path MTU Discovery
RFC 2582 - NewReno predecessor to 3782
RFC 1705 - suggests a TCPng
RFC 1144 - VJ TCP header compression
RFC 1078 - TCPMUX instead of well-known ports
RFC 962 - TCP-4 Prime (probably not worth adding?)
RFC 889 - includes analysis of RTT/RTO algorithm
RFC 794 - high-level discussion of pre-emption in TCP
RFC 761 - early TCP spec, pre 793
RFC 675 - early TCP spec
RFC 700 - early analysis
RFC 721 - discusses adding "interrupts"

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// mobile: (49-176) 32820027, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 2 Apr 2013 17:43:32 +0000

Hi Alex,

some random comments while reading your draft:

Pg 4, s/not-essential/non-essential/

Also, perhaps a hint should be given when there are Errata for the mentioned RFCs - particularly non-editorial ones (ie 1323 has a couple of those; but hopefully, 1323bis is published before the roadmap to update the reference :o) ).  I wonder how prevalent the checking of errata notes is, when someone looks up a RFC...

793 also has errata (Fernando Gont's acceptance test criteria update draft).

Sec3.1 s/ofnvery/of very/

Sec3.2 /and cannot distinguish between
   congestion-related loss and loss due to infer congestion,
   transmission errors.  

some mixup happened here? (trans. Err) after "to"?

s/could occours/could occur/

3.4 eifel detection missing - fwd reference to 4.2?

Section 7: FACK (SACK)?

Current developments (PRR, IW10)

Richard Scheffenegger

NetApp
[email-masked]
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com  

EURO PLAZA
Gebäude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Zimmermann
> Sent: Montag, 01. April 2013 20:13
> To: [email-masked] Extensions
> Subject: [tcpm] Roadmap for TCP - New Version
> 
> Hi Group,
> 
> today I finally submit a new version of the TCP roadmap. Sorry for the
> long delay :-) I include all new RFCs up to the new RFC 6897. Based on a
> email from Wes I also include all old, forgotten RFC into the roadmap (*).
> 
> introduce some new sections and subsections so that the reader can find
> more easily the RFCs in question. The new structure is fully aligned with
> RFC 5783 (Congestion Control in the RFC Series).
> 
> Happy for feedback
> Alex
> 
> ---
> 
> RFC 1078 - TCPMUX instead of well-known ports RFC 962 - TCP-4 Prime
> (probably not worth adding?) RFC 889 - includes analysis of RTT/RTO
> algorithm RFC 794 - high-level discussion of pre-emption in TCP RFC 761 -
> early TCP spec, pre 793 RFC 675 - early TCP spec RFC 700 - early analysis
> // Department of Computer Science, Informatik 4 // RWTH Aachen University
> // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax:
> (49-241) 80-22222 // email: [email-masked] // web:
> http://www.umic-mesh.net //
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 2 Apr 2013 20:28:25 +0200

>Section 7: FACK (SACK)?

Should be ok ;-)

>Current developments (PRR, IW10)

I support this section. It is hard to track current development if not reading
tcpm constantly. Or just a pointer to https://datatracker.ietf.org/wg/tcpm/ 

Hagen

-- 
http://protocollabs.com

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 02 Apr 2013 22:55:30 +0200

Bonjour Olivier,

indeed, it would make sense to exclude RFC 6356 and RFC 6824 from section 4.2 and
spend them a dedicated section. I share your opinion that MPTCP is much broader than
a congestion control extension. If you would like to send me some introduction text
for the new section that would be great! We can also include in the introduction
text some references to the other MPTCP RFCs, which are included in section

* 6.2. Architectural Guidelines - RFC 6182
* 6.4. Guidance for Developing, Analyzing, and Evaluating TCP - RFC 6181
* 6.5. Implementation Advice -  RFC 6897

Alex 

Am 02.04.2013 um 14:47 schrieb Olivier Bonaventure <[email-masked]>:

> Alexander,
> In the current version, you have included Multipath TCP RFCs in the congestion control section 4.2. I think that Multipath TCP would be worth a complete section in the document because it is much broader than a congestion control extension. I can propose some text if this can help
> 
> Best regards,
> 
> 
> Olivier Bonaventure
> 
> -- 
> INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

//

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 02 Apr 2013 23:20:26 +0200

Hi Richard,

thanks for the comments :-)

> Pg 4, s/not-essential/non-essential/

fixed

> Also, perhaps a hint should be given when there are Errata for the mentioned RFCs - particularly non-editorial ones (ie 1323 has a couple of those; but hopefully, 1323bis is published before the ro…

Why not... What do you propose? Like this?

RFC 6824 E: "TCP Extensions for Multipath Operation with Multiple
   Addresses" (January 2013) (Errata)

      This document [RFC6824] presents protocol changes required to add
      multipath capability to TCP; specifically, those for signaling and
      setting up multiple paths ("subflows"), managing these subflows,
      reassembly of data, and termination of sessions.

Or completely different?

> Sec3.1 s/ofnvery/of very/

fixed

> some mixup happened here? (trans. Err) after "to"?

fixed. Must be a C&P error...

> s/could occours/could occur/

fixed

> 3.4 eifel detection missing - fwd reference to 4.2?

Eifel detection is still experimental... (as well as DSACK)
We can include the fwd ref into the missing intro text of
sec. 3.4. OK?

> Section 7: FACK (SACK)?

Yes as well as CUBIC and CompoundTCP

> Current developments (PRR, IW10)

OK. Make sense. I will do that.

Alex

//

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 02 Apr 2013 23:22:11 +0200

Hi Hagen,

you support this section with some text? ;-)

Alex

//

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 2 Apr 2013 21:32:05 +0000

Hi Alex,

>       reassembly of data, and termination of sessions.

Yes, something light-weight like that, when technical errata that affect the mechanisms exist.

> Eifel detection is still experimental... (as well as DSACK) We can include
> the fwd ref into the missing intro text of sec. 3.4. OK?

Ok; 

> Yes as well as CUBIC and CompoundTCP

For cubic and CTCP there are some (expired) drafts, at least:

http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02

http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02

I think the only ietf draft so far describing FACK is

http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01#section-2.2

Richard Scheffenegger

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 02 Apr 2013 23:39:11 +0200

> http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01#section-2.2

I little bit hidden, but FACK is also included in this draft:

http://tools.ietf.org/html/draft-mathis-tcp-ratehalving-00

Alex

//

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 3 Apr 2013 06:48:31 +0000

> Current developments (PRR, IW10)

Won't this section be perpetually outdated? 

Also, given the ephemeral nature of I-Ds, I don't think we should burn energy trying to track them. Those that become RFCs can get added to the roadmap when they do.

Lars

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 3 Apr 2013 10:07:19 +0200

>Won't this section be perpetually outdated?

In the long term yes. But at the end it boils down that a) an I-D was becoming
an RFC or b) something happened on that way. That "something" may be of
interest for the readers too. For me a handy document is where all development
is listed, this should include IW10 and similar topics.

Another way is to follow my other idea: provide a reference to [1].

Hagen

[1] https://datatracker.ietf.org/wg/tcpm/

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 3 Apr 2013 08:11:22 +0000

Hi,

> is listed, this should include IW10 and similar topics.

yeah, but the point of the document isn't to be a history of TCP standardization efforts. It's a "start reading here" document for the TCP-related RFCs. We have mailing list archives and meeting minutes to help people figure out the "what happened" part.

Lars

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 3 Apr 2013 08:23:18 +0000

Hi,

My original though was actually to include only those I-Ds/papers, which are either

a) widely deployed even though not a formal RFC (FACK, Cubic, CTCP)

b) current WG items, that are clearly (at least my impression) on the road to become, or are already an RFC (IW10, PRR, ExOpt).

Regarding MPTCP, I don't have a clear opinion right now. If that is included, it would surely warrant a section/subsection of its own.

Richard Scheffenegger

> From: Eggert, Lars
> Sent: Mittwoch, 03. April 2013 10:11
> To: Hagen Paul Pfeifer
> Cc: Scheffenegger, Richard; tcpm ([email-masked])
> Subject: Re: [tcpm] Roadmap for TCP - New Version
> 
> Hi,
> 
> > In the long term yes. But at the end it boils down that a) an I-D was
> > becoming an RFC or b) something happened on that way. That "something"
> > may be of interest for the readers too. For me a handy document is
> > where all development is listed, this should include IW10 and similar
> topics.
> 
> yeah, but the point of the document isn't to be a history of TCP
> standardization efforts. It's a "start reading here" document for the TCP-
> related RFCs. We have mailing list archives and meeting minutes to help
> people figure out the "what happened" part.
> 
> Lars

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 3 Apr 2013 10:24:12 +0200

* Eggert, Lars | 2013-04-03 08:11:22 [+0000]:

>standardization efforts. It's a "start reading here" document for the
>TCP-related RFCs. We have mailing list archives and meeting minutes to help

Right, I don't wanted to focus on the history part. I wanted to provide the
ongoing effort, the (eventual) future of TCP. Efforts like the mentioned IW10.
I mean for a IETF professional like Lars, who knows about IETF mailing list,
IETF structure and websites it may sound simple. But for software guys,
requirement engineers, new students it is hard to get the broader picture.

But yes, I understand that this section will make the document more "fuzzy".
I have no shares here so I don't mind.

Hagen

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 3 Apr 2013 11:04:46 +0200

> a) widely deployed even though not a formal RFC (FACK, Cubic, CTCP)

I do believe that stuff that is really widely deployed in the Internet should be refered to in "7. Undocumented TCP Features" (possibly having several subsection).

But we shouldn't try to document every congestion control algorithm that was ever presented to ICCRG (or elsewhere) ;)

> b) current WG items, that are clearly (at least my 
> impression) on the road to become, or are already an RFC 
> (IW10, PRR, ExOpt).

Unless something strange happens, those three should be an RFC when this document will be published. I think it is fine to refer to them now.

> Regarding MPTCP, I don't have a clear opinion right now. If 
> that is included, it would surely warrant a 
> section/subsection of its own.

I do believe it should very briefly be mentioned, e.g. as Section 4.6.

Michael (chair hat off)

> > > In the long term yes. But at the end it boils down that a) an I-D 
> > > was becoming an RFC or b) something happened on that way. 
> That "something"
> > TCP- related RFCs. We have mailing list archives and 
> meeting minutes 
> > to help people figure out the "what happened" part.
> > 
> > Lars