Subject: Re: [tcpm] TCPM rechartering discussion

From: Yuchung Cheng <[email-masked]>
Date: Mon, 5 Mar 2012 18:17:10 -0800

Are middleboxes issues (NAT messing up TCP) part of the charter.

also is there an RFC (or draft) for this ?
" * The WG is writing an informational document about the ways in
which TCPs can handle ICMP "soft errors". "

Thanks,

Yuchung

On Mon, Feb 20, 2012 at 2:19 AM, SCHARF, Michael
<[email-masked]> wrote:
> Dear all,
>
> The current TCPM charter https://datatracker.ietf.org/wg/tcpm/charter/
> includes some outdated text. Most notably, the "Specific Goals"
> mentioned in the charter are not up to date. Also, the current charter
> requires IESG approval of every new milestone.
>
> Therefore, the chairs think that it would make sense to recharter TCPM
> in order to clean up the completed goals and to make it easier to manage
> future milestones. Please find below a first draft for a new charter
> text. The intention is a minor modification that does not to affect the
> overall scope of the working group.
>
> We would highly appreciate comments or suggestions.
>
> Best regards
>
> Michael (TCPM co-chair)
>
>
>
>
> TCP Maintenance and Minor Extensions (tcpm)
> -------------------------------------------
>
> Description of Working Group: ***DRAFT***
>
> TCP is currently the Internet's predominant transport protocol.
> To maintain TCP's utility the IETF has regularly updated both
> the protocol itself and the congestion control algorithms
> implemented by the protocol that are crucial for the stability
> of the Internet. These changes reflect our evolving
> understanding of transport protocols, congestion control and new
> needs presented by an ever-changing network. The TCPM WG provides
> a venue within the IETF to work on these issues. The WG
> serves several purposes:
>
> * The WG mostly focuses on maintenance issues (e.g., bug
> fixes) and modest changes to the protocol and algorithms
> that maintain TCP's utility, including incremental enhancements
> of the congestion control mechanisms.
>
> * 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 are minor extensions to TCP
> algorithms and mechanisms. In cases where these are
> directly applicable to other transports (e.g. SCTP or DCCP),
> the mappings to other transports may be specified alongside
> that for TCP, but significant additions and changes to other
> transports are not in scope.
>
> TCPM is the working group within the IETF that handles small TCP
> changes, or minor extensions to TCP algorithms and mechanisms. While
> fundamental changes to TCP or its congestion control algorithms
> (e.g., departure from loss-based congestion control) should be brought
> through TCPM, it is expected that such large changes will be handled
> by other working groups or require additional reviews, in particular by
> the IRTF Congestion Control Research Group (ICCRG).
>
> TCP's congestion control algorithms are the model followed by
> alternate transports (e.g., SCTP and (in some cases) DCCP),
> which are handled for instance by the Transport Area WG (tsvwg).
> The IETF has recently 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 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 approval of the working group and the
> responsible Area Director.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 06 Mar 2012 09:03:39 +0100

Hi Yuchung,

> which TCPs can handle ICMP "soft errors". "

See RFC 5461: TCP's Reaction to Soft Errors

and

RFC 5927 ICMP: attacks against TCP

Alex

> <[email-masked]> wrote:

//
// 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: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 6 Mar 2012 13:05:07 +0100

Yuchung, 

> Are middleboxes issues (NAT messing up TCP) part of the charter.
 
Good question. We have in the charter (both in the current and in the proposed update) the statement that the "WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility [...]".

As a result, I think that potential minor modifications of the TCP protocol to improve the interoperability of TCP's existing service with NATs would be in scope of the charter. Of course, provided that there is indeed a real need for such modifications, consensus in TCPM, etc.

Do you suggest a rephrasing of the charter text?

> " * The WG is writing an informational document about the 
> ways in which TCPs can handle ICMP "soft errors". "

As already pointed out by Alex, this part of the current TCPM charter is really outdated. Removing the legacy text is one key motivation for this charter update discussion.

Thanks for the feedback

Michael

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 13:25:55 +0000

Um, RFC 5461, TCP's Reaction to Soft Errors? 

http://tools.ietf.org/html/rfc5461

http://www.gont.com.ar/papers/index.html
http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html
may also be of interest.

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

Thanks for the feedback

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 6 Mar 2012 14:35:57 +0100

Isn't this what RFC 5927 is about?

RFC 5927/draft-ietf-tcpm-icmp-attacks dates back quite some time...

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2012 2:26 PM
> To: Scharf, Michael (Michael); [email-masked]
> Cc: [email-masked]
> Subject: RE: [tcpm] TCPM rechartering discussion
> 
> As already pointed out by Alex, this part of the current TCPM 
> charter is really outdated. Removing the legacy text is one 
> key motivation for this charter update discussion.
> 
> Thanks for the feedback
> 
> Michael
>

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 6 Mar 2012 16:42:41 -0800

> As a result, I think that potential minor modifications of the TCP protocol to improve the interoperability of TCP's existing service with NATs would be in scope of the charter. Of course, provided…

Great! is there any guideline on middlebox cooking up new TCP headers?
e.g., draft-ananth-middisc-tcpopt-00.tx

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Mar 2012 17:14:31 -0800

> Great! is there any guideline on middlebox cooking up new TCP headers?

Check with the MIDCOM WG.

However, in general, I'd say "don't" ;-)

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 6 Mar 2012 17:22:42 -0800

Yuchung,
     I think I need to explain some context here..

> e.g., draft-ananth-middisc-tcpopt-00.tx

A few years back there was a draft which talked about transparent
middlebox discovery
(http://tools.ietf.org/html/draft-knutsen-tcpm-middlebox-discovery-03 )
and seeking a TCP option for the same that would be used by the
middleboxes. TCPM decided not to take up that work and an alias was
formed (with the blessings of the transport AD's) which was used by
multiple vendors doing WAN optimization to discuss and converge upon a
single TCP option format. The main goal of this is to dis-courage
vendors from doing TCP option poaching and using the TCP options
officially unassigned by IANA for middlebox services like Wan
optimization etc., 

I am trying to interpret your comment on "middlebox cooking up new TCP
headers", Well middleboxes are there and they do connection termination
and optimization (Performance enhancing proxies), for quite some time in
the internet as you probably are aware. The issue the middisc draft is
trying to address is to get all vendors try using a single TCP option
code point and stop using unassigned TCP option code points. 

-Anantha

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Mar 2012 09:35:39 +0100

> > Good question. We have in the charter (both in the current 
> and in the proposed update) the statement that the "WG mostly 
> focuses on maintenance issues (e.g., bug fixes) and modest 
> changes to the protocol and algorithms that maintain TCP's 
> utility [...]".
> >
> > As a result, I think that potential minor modifications of 
> the TCP protocol to improve the interoperability of TCP's 
> existing service with NATs would be in scope of the charter. 
> Of course, provided that there is indeed a real need for such 
> modifications, consensus in TCPM, etc.
> 

Note that I stated that "interoperability of TCP's existing service" might be in scope of TCPM. In my understanding, middlebox discovery would be a function beyond what TCP offers today.

The TCPM charter explicitly states that the WG only deals with minor TCP extensions, and other working groups might be needed otherwise. IMHO it makes sense to raise awareness about work such as draft-ananth-middisc-tcpopt in TCPM (and this discussion is thus helpful). In my understanding, this doesn't imply that TCPM will be the best place to home such work.

Michael