Subject: [tcpm] Charter update - feedback

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 25 Apr 2012 10:23:26 +0200

Dear all,

we rephrased the suggested TCPM charter update based on the feedback received so far. Most notably, we tried to address the comments from Gorry, Lars, and Matt in Paris, and we removed some duplicate text. We also rephrased the paragraph regarding congestion control in order to emphasize that TCPM's focus is protocol standardization, not research of algorithms.

As already mentioned, the intention is just to get rid of legacy text in the current charter - the scope of TCPM shall not be changed or extended.

Please let us know if you have any suggestions or comments.

Thanks

Michael

TCP Maintenance and Minor Extensions (tcpm)
-------------------------------------------

Description of Working Group: ***DRAFT***

TCP is currently the Internet's predominant transport protocol.
TCPM is the working group within the IETF that handles small TCP
changes, i.e., minor extensions to TCP algorithms and protocol
mechanisms. The TCPM WG serves several purposes: 

* The WG mostly focuses on maintenance issues (e.g., bug 
fixes) and modest changes to the protocol, algorithms, and
interfaces that maintain TCP's utility.

* The WG is a venue for moving current TCP specifications 
along the standards track (as community energy is available 
for such efforts). 

* The focus of the working group is TCP. In cases where small
changes are directly applicable to other transports (e.g., SCTP
or DCCP), the mappings to other transports may be specified
alongside that for TCP, but other significant additions and changes
to other transports are not in scope.

TCPM also provides a venue for standardization of incremental
enhancements of TCP's standard congestion control, but such changes
may require additional review by the IRTF Congestion Control Research
Group (ICCRG). Fundamental changes to TCP or its congestion control
algorithms (e.g., departure from loss-based congestion control) will
be handled by other working groups or will require rechartering.

TCP's congestion control algorithms are the model followed by alternate
transports (e.g., SCTP or DCCP), which are standardized in other
working groups, such as the Transport Area WG (tsvwg). In the past, the
IETF has worked on several documents about algorithms that are specified
for multiple protocols (e.g., TCP and SCTP) in the same document. Which
WG shepherds such documents will be determined on a case-by-case basis. In
any case, the TCPM WG will remain in close contact with other relevant
WGs working on these protocols to ensure openness and stringent review
from all angles.

New TCPM milestones that fall within the scope specified within
the charter can be added after concensus on acceptance in the working
group and approval by the responsible Area Director.

---

From: John Leslie <[email-masked]>
Date: Wed, 25 Apr 2012 10:40:23 -0400

Scharf, Michael (Michael) <[email-masked]> wrote:
> 
> As already mentioned, the intention is just to get rid of legacy text
> in the current charter - the scope of TCPM shall not be changed or
> extended.

   Hmm... "rechartering" to me implies at least clarification of scope
where it is ambiguous...

> Please let us know if you have any suggestions or comments.

   Neither the current charter nor this proposed one clearly encourages
or discourages work on what I'll call "expanding TCP option space" -- by
which I mean almost anything to reduce the logjam of options trying to
squeeze into 40 bytes.

   IMHO, this deserves very high priority, and can be sufficiently
solved if we just accept it as a priority.

   In any case, it is my strong belief that either
- we should work on it, or
- we should send this work somewhere else.

   I specifically ask that we clarify whether such work is in-scope.

--
John Leslie <[email-masked]>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 25 Apr 2012 08:38:36 -0700

John, People introduce ideas to extend the option space from time to
time.   I don't think they are excluded from tcpm (or other places for
that matter), however no such idea has succeeded in "leaving the
launch pad".   Usually there is an obvious flaw that the author failed
to notice but gets discovered fairly quickly in hallway conversations.

I even heard a new one in Paris, that wasn't quite fleshed out enough
to be an ID yet.

Many many people have worked on this from time to time, but legacy and
NATs kill everything.

If somebody discovers something new, that seems to work they will have
no trouble getting attention in tcpm, I assure you.   There may be a
conversation with the chairs or ADs to select which WG, but it would
not be a barrier to being introduced someplace.

Generally IETF WGs don't take on work for which there are no workable
solutions on the table.   That role belongs to the IRTF.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Wed, Apr 25, 2012 at 7:40 AM, John Leslie <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Apr 2012 08:47:10 -0700

On Apr 25, 2012, at 7:40 AM, John Leslie wrote:
...
>   I specifically ask that we clarify whether such work is in-scope.

The charter shouldn't make that conclusion, IMO. That's for the WG to decide based on a given proposal.

If you have a *viable* (see below) proposal, let's hear it...

Viable, IMO:
- compatible with legacy TCP in the same SYN exchange
- compatible with known proxy behavior, including segment rewriting (where not already prevented by authentication or encryption)
- extends the space of SYNs not just subsequent segments

AFAICT, that set is null. It'd also be nice to be able to know when it fails because an intermediate interferes but the endpoints agreed, but I'm not sure that's a strict requirement.

There is only one solution I've ever heard of that might work at all - TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 25 Apr 2012 19:11:21 +0200

>    Neither the current charter nor this proposed one clearly 
> encourages or discourages work on what I'll call "expanding 
> TCP option space" -- by which I mean almost anything to 
> reduce the logjam of options trying to squeeze into 40 bytes.
>
>    IMHO, this deserves very high priority, and can be 
> sufficiently solved if we just accept it as a priority.
> 

My view on this is:

1. A survey and analysis of the problems of option space extension could be in-scope of the existing TCPM charter, as well as the suggested charter update (since the scope is the same), provided that the well-known constraints are fulfilled, e. g., WG energy and consensus on a document.

2. At least a subset of the known solutions seems to be beyond a minor TCP modification (e. g., TCPx2), and therefore they might not be in scope of the current or suggested new TCPM charter.

My understanding is that we currently don't have consensus whether the problem can indeed be solved in a non-disruptive way, and we don't known if such a solution could/would get deployed in the Internet. Given that constraints, I think that the TCPM charter must not ask for a solution right now. The charter can obviously be changed once we have more support in the community and consensus regarding solutions.

Anyway, TCPM certainly welcomes further technical discussions.

Michael

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 25 Apr 2012 13:19:54 -0400

>> - we should send this work somewhere else.

I believe this (TCPM) is the place, if such work is to be done.
Anantha's draft (and the collected email archives since maybe
2004ish) pretty clearly show that TCPM *has* been working on
this for some time, and has simply not found an acceptable
solution with consensus to proceed:
https://datatracker.ietf.org/doc/draft-ananth-tcpm-tcpoptext/

> The charter shouldn't make that conclusion, IMO. That's for the WG to decide based on a given proposal.

Agreed; if an approach exists to support it as a "minor extension"
then it would be in scope, but that needs to be evaluated along
with the viability of a given proposal.

I would support (as individual and as AD) doing an Informational
snapshot of the collected thoughts and proposals to-date and why
each has fallen down.  It could be a milestone though and not
necessarily part of the charter text.  I think Anantha's document
is a reasonable starting point and the approach of trying to
identify requirements to evaluate against echoes Joe's three
criteria for a solution which he's reiterated several times to the
list, and I think are somewhat accepted.

-- 
Wes Eddy
MTI Systems

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 25 Apr 2012 10:59:24 -0700

<Catching up>

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Matt Mathis
> Sent: Wednesday, April 25, 2012 8:39 AM
> To: John Leslie
> Cc: tcpm IETF list
> Subject: Re: [tcpm] Charter update - feedback
> 

I don't want to cause a rat-hole on this topic. I assume you are talking
about :-

http://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00

Yes, the TCP option space issue has been discussed before, yes there
were proposals on table. Nothing went forward. ?One of the main reasons
was : Initially the TCP option space issue was perceived as "solution in
search of a problem" when there were some early proposals made on this
topic. Of course every solution had the issue with middleboxes (with
varying degrees) Things changed later on, many folks including the
chairs were happy to revisit this discussion, at least to document the
issues, instead of having periodic email discussions now and then and
then let it die. This is the reason I (volunteered) wrote the ID, main
motivation to rejuvenate the discussions and document whatever the comes
out it. I would like to add that, if we can simply the requirements,
then there is a scope for arriving at a solution that probably works for
most of the cases and rest of cases it may not (IMO). [ can I point out
many RFC's where caveats are made and documented and moved on] FWIW, in
my document I cite a reference which did some experimentation on
middleboxes and came to conclusion that "it is still possible to extend
TCP, but careful design choices need to be made".

So please read the document and provide comments. If this topic is not
as interesting as some congestion/flow control change, SACK extensions,
Initial window change OR TCP fast open or any such thing, then that is
fine, so be it. I don't need to beat the drum again to emphasize how
important this problem for TCP's evolution. IMO, this work is fully
within the scope of TCPM, many folks are interested to revive this
discussion. For example things like "Timestamps modification
suggestion", where you don't need to send timestamps every packet or on
3 way handshake are useful extensions (FWIW, the TCP option space
document also mentions it). I think, Tim Shepherd came to the mike when
I quickly presented in Paris and mentioned some 80 bits (am I saying
this correct?) of the TCP header that can be "reused" to scavenge TCP
option space. We haven't really had discussions (forward looking) to
continue those ideas and beat it to death. I am sure if we chose to move
along discussing this seriously, there would more ideas on table and
maybe we can converge with something.

Ok, I guess we need to answer the following questions :- 

- do we want revive TCP option space issue discussions given that it has
become a real issue now?
- If so, can we use the above document as a starting point? Or any other
plans?

If we cannot answer the above 2 simple questions, I see no value in this
discussion. 

Chairs, can you outline the next steps for this document? As what needs
to be done w.r.t the document? (above link)

$0.02,
-Anantha

PS:  Joe, in case you are planning to reply to this email, then can you
please focus on the above 2 questions, Yes I heard your viewpoints are
but I have simply expressed my opinion, hence I feel there is no need to
nitpick on some statements above. 

<snip>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 25 Apr 2012 11:11:20 -0700

> - compatible with known proxy behavior, including segment rewriting
> (where not already prevented by authentication or encryption)
> AFAICT, that set is null. It'd also be nice to be able to know when it
> fails because an intermediate interferes but the endpoints agreed, but
> I'm not sure that's a strict requirement.
> 
> There is only one solution I've ever heard of that might work at all -
> TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.

Well, I am afraid that is not the universal opinion, just your opinion.
For instance you were opposed on the timestamps modification proposal
which others supported. Some folks are fine to "if we have to fire up 2
SYN's" but you weren't. If we want to list the requirements of what all
conditions that TCP option space proposals need to satisfy, we can list
it. (my document already classifies it to some extent) We can also need
debate as to which conditions that can be relaxed. (MUST/SHOULD/MAY if
you wiil). We can't jump to a solution unless there is a consensus on
the requirements.

[Just to avoid going round in circles]

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Apr 2012 11:15:14 -0700

Hi, all,

On 4/25/2012 10:59 AM, Anantha Ramaiah (ananth) wrote:
...
> - do we want revive TCP option space issue discussions given that it has

You suggest earlier attempts were viewed as proposed solutions in search 
of a problem.

The issue has, IMO, always been (and continues to be):

	regardless of the problem or need,
	does a viable solution exist?

I gave a list of requirements for a viable solution. We should start by 
agreeing on that set before *assuming* a solution exists.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Apr 2012 11:19:06 -0700

On 4/25/2012 11:11 AM, Anantha Ramaiah (ananth) wrote:
> which others supported.

I demonstrated problems with them.

> Some folks are fine to "if we have to fire up 2
> SYN's" but you weren't.

I demonstrated problems with them too - notably when an endpoint uses L2 
load balancing.

 > If we want to list the requirements of what all

Yes, I agree.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 25 Apr 2012 11:28:47 -0700

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2012 11:19 AM
> To: Anantha Ramaiah (ananth)
> Cc: John Leslie; tcpm IETF list
> >> The charter shouldn't make that conclusion, IMO. That's for the WG
> to
> >> decide based on a given proposal.
> >>
> >> AFAICT, that set is null. It'd also be nice to be able to know when
> >> it fails because an intermediate interferes but the endpoints
> agreed,
> >> but I'm not sure that's a strict requirement.
> >>
> >> There is only one solution I've ever heard of that might work at
all
> >> -
> > Some folks are fine to "if we have to fire up 2 SYN's" but you
> > weren't.
> 
> I demonstrated problems with them too - notably when an endpoint uses
> L2 load balancing.

Fine, you "demonstrated some problems" but that doesn't mean that we
can't continue discussing them  esp, when there are others who did not
think there was a "demonstrated problem" :-)

> > conditions that TCP option space proposals need to satisfy, we can
> > list it. (my document already classifies it to some extent) We can
> > also need debate as to which conditions that can be relaxed.
> > (MUST/SHOULD/MAY if you wiil). We can't jump to a solution unless
> > there is a consensus on the requirements.
> 
> Yes, I agree.

Ok, then. I am fine to take that route (IMO, the logical route) we
always do this in any product development, don't we ? Requirements first
and solution next.  IMO, the document attempts to support such a line of
thinking.  I'll let chairs to decide on the next steps.

-Anantha

---

From: John Leslie <[email-masked]>
Date: Wed, 25 Apr 2012 14:46:24 -0400

I apologize if this is out-of-scope, but it feels at least as in-scope
as what I'm responding to:

Wesley Eddy <[email-masked]> wrote:
>> to decide based on a given proposal.
> 
> necessarily part of the charter text.

   That is acceptable to me.

> I think Anantha's document is a reasonable starting point and the
> approach of trying to identify requirements to evaluate against
> echoes Joe's three criteria for a solution which he's reiterated
> several times to the list, and I think are somewhat accepted.

   "Somewhat accepted" may overstate the case...

>> - compatible with legacy TCP in the same SYN exchange

   This is easy. I think we do accept this.

>>   (where not already prevented by authentication or encryption)

   This is open-ended. I think we need to list proxy behaviors we
wish to be "compatible" with -- and we should clarify what we mean
by "compatible". (Clearly, we can't expect to get option negotiation
through a proxy which strips out every attempt, but we can recognize
that our attempts are being stripped.)

>> - extends the space of SYNs not just subsequent segments

   We should be able to extend the space in the responding SYN, but
not in the originating SYN. What we need instead is to enable
additional options from the originating endpoint to be processed
"as if they were in an initial SYN".

   Given rewording to that effect, I think the requirements would be
reasonable to include in a tcp-option-extension Informational RFC.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 25 Apr 2012 21:31:00 +0200

> - do we want revive TCP option space issue discussions given 
> that it has become a real issue now?
> - If so, can we use the above document as a starting point? 
> Or any other plans?
> 
> If we cannot answer the above 2 simple questions, I see no 
> value in this discussion. 
> 
> Chairs, can you outline the next steps for this document? As 
> what needs to be done w.r.t the document? (above link)

I agree with Wes that a document that surveys and analyzes existing proposals would be helpful, heading for informational. I think that your draft is a good starting point for such a survey,
and it would be important to include the mailing list feedback and then present an updated version in the next meeting, to have more discussion time. (Note that the draft was submitted post-deadline for Paris.)

As individual, my impression that the draft requires more work before it can become a WG item.

For instance, I think that the requirement H1 would benefit from a more fine-grained analysis. Some keywords out of my head (sorry, I've not carefully thought of that list): interaction with data in SYNs?, SYN cookies?, issues with concurrent SYNs?, TCP offloading impact?, robustness to packet-reordering?, load balancing?, etc. It would be excellent to first come up with a comprehensive list of possible problems, and then match the known schemes against this, in order to show what the downsides and costs are. Obviously, the requirements for SYNs and non-SYNs are different.

I also don't know whether the solution list is complete. For instance, RFC 6013 happens to talk about option space extension... And, BTW, some naive guy asked a naive question a long time ago: http://www.ietf.org/mail-archive/web/tcpm/current/msg03700.html ;) The list thread explains why that question was really naive. But there might be more ideas like that out there. 

Also as indivudual, I would disagree with the scope of the document if the plan was to converge or specify a (single) solution therein. I could understand the current title and abstract in this way. A better wording for the title would be something like "Survey and analysis of TCP option space extensions proposals". In my optionion, it would make sense to first work on a document that comprehensively lists the problems and surveys known solution, and have consensus on the list of pros and cons... That document does not have trade them off. Any any actual specification should be done separately.

Michael

PS: I am personally convinced that TCPM should adopt documents once their content is somewhat mature (i. e., not necessarily -00).

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 26 Apr 2012 14:19:09 +0000

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

> From: Joe Touch
> Sent: Mittwoch, 25. April 2012 20:19

True; However, the timestamp option is one of the few (legacy) options, where the lack of support (or unsuccessful negotiation) does not threaten an existing flow; RTTM and thus RTO calculation become less frequent, and there exists a chance of accepting old packets which can corrupt the data (under specific circumstances).

But especially with timestamps, a "soft" negotiation - sending them for 1 RTT window worth of packets, and discontinue if the receiver doesn't react - should be rather straight forwards. 

I also agree, we will have to work out the feasibility of this approach (i.e. will certain home routers reboot when they encounter timestamps in a flow where they didn't expect them? Or a NAT / IDS drop all subsequent packets, effectively terminating the connection - but wouldn't that rather be broken behavior of a non-conformant middlebox rather then a shortcoming of the mechanism? And do we really need to carter for all the implementation bugs or broken configurations? ). 

Coming up with a generic means of reliably negotiating options during a session - as a side mechanism of TCP - may be another worthwhile effort.

Of course, some features / functionalities simply don't lend themselves to "late" negotiation (i.e. MSS must be known before data packets flow; WS could, however, be made dynamic, if carried with each segment - perhaps in some of Tim's "orphaned" bits, with an implicit scaling of 0 if not signaled. Which, BTW, should address the issue Matt pointed out w.r.t. window scaling and deadlocks on window reductions.

I think, one key point here is, that whenever a new SYN option is proposed, to also check if this really needs to be a one-time negotiation during the handshake, or if such a mechanism could work with its signaling being unreliable during the actual flow. That would not address the core issue (limited option space during SYN), but perhaps alleviate some of the pressure?

Best regards,
   Richard

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 26 Apr 2012 16:48:40 +0200

> I think, one key point here is, that whenever a new SYN 
> option is proposed, to also check if this really needs to be 
> a one-time negotiation during the handshake, or if such a 
> mechanism could work with its signaling being unreliable 
> during the actual flow. That would not address the core issue 
> (limited option space during SYN), but perhaps alleviate some 
> of the pressure?

For what it is worth, I've posted on the MPTCP list recently that this approach should be carefully studied when going to StdTrack, for the option that has to negotiate the use of MPTCP and that thus should be present in every SYN. In my understanding, MPTCP requires reliable transport of some control data in non-SYN segments anyway.

I still try to fully understand the trade-off between postponing of information transport to non-SYNs vs. a full option space extension scheme allowing more than 40B in segments. Apparently, there is overlap between both approaches.

Michael (random researcher)