Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 8 Jul 2016 23:18:42 +0200

Hi,

We just submitted this draft for consideration of the WG. Comments are 
appreciated.

Regards, marcelo

-------- Mensaje reenviado --------
Asunto: 	I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt
Fecha: 	Fri, 08 Jul 2016 14:16:35 -0700
De: 	[email-masked]
Responder a: 	[email-masked]
Para: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Recommendations for increasing TCP performance in low RTT networks.
         Authors         : Marcelo Bagnulo
                           Koen De Schepper
                           Glenn Judd
	Filename        : draft-bagnulo-tcpm-tcp-low-rtt-00.txt
	Pages           : 7
	Date            : 2016-07-08

Abstract:
    This documents compiles a set of issues that negatively affect TCP
    performance in low RTT networks as well as the recommendations to
    overcome them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 18:00:46 -0700

Hi, Marcelo (et al.),

- regarding the receive buffer (Sec 5):

There are TCPs that autoconfigure this value, but it's not part of the
protocol spec - it's an "app layer" resource as far as TCP is concerned.
Although it's useful to discuss here, it needs to be considered as
external to the protocol.

The size of the receive buffer limits TCP performance only in the
following ways:
    - it needs to be large enough to accommodate reordering
    - it needs to be large enough to hold arriving data while gaps are
filled-in (using SACK or timeouts)
    - it needs to buffer enough data between OS scheduling of the user
app that drains the buffer
    - the buffer size is limited by what the OS allocates to the
connection (either by default or by user override)

The first two are things TCP could measure and tune, but generally the
last two are the constraining factors.

Joe

On 7/8/2016 2:18 PM, marcelo bagnulo braun wrote:
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm