Subject: [tcpm] working group status 11/17/09

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 17 Nov 2009 08:23:06 -0600

Hello; since TCPM didn't meet in Hiroshima, but we do have
several documents in the process of being finished up, and
a couple others in the process of starting, here's a quick
snapshot of the TCPM working group status and the actions
needed on each document; please let us know if we left
anything out:

Active WG Items
===============

TCP Authentication Option
http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt
Milestone Target: Proposed Standard in April 2009
Action: In WGLC until 11/24/09

TCP Authentication Option Crypto
http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt
Milestone Target: Proposed Standard with AO spec
Action: In WGLC until 11/24/09

ICMP Attacks
http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt
Milestone Target: Informational in July 2009
Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based on WGLC

Early-Retransmit
http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt
Milestone Target: Experimental in July 2009
Action: WGLC finished & authors updated (action with chairs to forward to IESG)

1323bis
http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt
Milestone Target: Proposed Standard in July 2009
Action: Revise & WGLC (action with D. Borman)

MSS Option
http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt
Milestone Target: Proposed Standard in July 2009
Action: WGLC started 8/19, ended 9/8 (extended), being updated based on several
        of the comments (action with D. Borman)

Urgent Pointer
http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt
Milestone Target: Proposed Standard in January 2010
Action: Continue WG reviews; authors have indicated it is ready for WGLC;
        planned to start WGLC after AO WGLC completes

TCP Security
http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt
Milestone Target: BCP in August 2010
Action: 00-draft / outline has been under active discussion; but not attained
          very clear consensus
        WG might begin working on recommendations while still looking for a
          possible compromise on outline (action with Fernando Gont)

Long Connectivity Disruptions
http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt
(need to submit WG version)
Milestone Target: Experimental in October 2010
Action: need WG to read/discuss
        authors to submit revision (action with Zimmerman)

SACK Entry
http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt
Milestone Target: Proposed Standard in October 2010
Action: need WG to read/discuss
        TBD how this relates to 3517

Other Proposals
===============

Persist
http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt
Action: WG Review

Timestamps
http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt
Action: ???

Parameter Tuning
(no I-D yet)
Action: continue good discussion on mailing list
        presentation given in Stockholm

TCP Option for Transparent Middlebox Discovery
http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt
Action: Needs WG review / discussion
        discussion on mailing list has been productive

NewReno Modification
http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt
Action: need WG to read/discuss
        presentation given, but WG list not yet polled for adoption

Recent discussions opened on Rate-Halving
http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt
Action: mailing list discussion about the history of this, and whether
        it needs to be revived

--
Wes Eddy
MTI Systems

---

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 17 Nov 2009 13:54:09 -0800

should we also list here the current draft on NAT-Traversal for TCP-AO? It's
not a WG item, but it is being done as a possible (likely?) textual addition
to a WG item. comment?

Gregory.

On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE
CORP] <[email-masked]> wrote:

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

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Nov 2009 14:16:05 -0800

Hi, Gregory,

Gregory Lebovitz wrote:
> should we also list here the current draft on NAT-Traversal for TCP-AO?
> It's not a WG item, but it is being done as a possible (likely?) textual
> addition to a WG item. comment?

It might be useful. I know there are a few people who said they might
post their thoughts on this shortly... (i.e., this is a reminder to them ;-)

Joe

> On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC
> AEROSPACE CORP] <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 18 Nov 2009 11:17:53 -0000

Hello Group,

Regarding Rate-Halving: It seems to me, that RFC4653 has a "lite" 
version (Cautious Extended Limited Transmit) of that, and limiting 
the scope to SACK-enabled streams only.

Also, RR-TCP uses Extended Limited Transmit (but the aggressive 
variant) to keep the ACK clock going after potential congestion events. 
But RR-TCP seems to be very much more complex than RFC4653, although 
I need to investigate the gains/costs a bit further.

I wonder if the mentioned problems wouldn't impact those suggested 
algorithms just like RH; OTOH, data handling subsystems are getting
Also faster, so that at least starvation during a bulk transfer (in
a dedicated system) should no longer be a hinderance. And worst case 
operation wouldn't be so much different from NewReno anyway, or not?

Regards,

Richard Scheffenegger
Field Support Engineer
NetApp Global Support
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com
Franz-Klein-Gasse 5
1190 Wien

-----Original Message-----
From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
[mailto:[email-masked]] 
Sent: Dienstag, 17. November 2009 15:23
To: [email-masked]
Subject: [tcpm] working group status 11/17/09

Hello; since TCPM didn't meet in Hiroshima, but we do have several
documents in the process of being finished up, and a couple others in
the process of starting, here's a quick snapshot of the TCPM working
group status and the actions needed on each document; please let us know
if we left anything out:

Active WG Items
===============

ICMP Attacks
http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt
Milestone Target: Informational in July 2009
Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based
on WGLC

Early-Retransmit
http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt
Milestone Target: Experimental in July 2009
Action: WGLC finished & authors updated (action with chairs to forward
to IESG)

1323bis

MSS Option
http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt
Milestone Target: Proposed Standard in July 2009
Action: WGLC started 8/19, ended 9/8 (extended), being updated based on
several
        of the comments (action with D. Borman)

Urgent Pointer
http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt
Milestone Target: Proposed Standard in January 2010
Action: Continue WG reviews; authors have indicated it is ready for
WGLC;
        planned to start WGLC after AO WGLC completes

TCP Security
http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt
Milestone Target: BCP in August 2010
Action: 00-draft / outline has been under active discussion; but not
attained
          very clear consensus
        WG might begin working on recommendations while still looking
for a
          possible compromise on outline (action with Fernando Gont)

SACK Entry

Other Proposals
===============

Persist

Timestamps

Parameter Tuning
(no I-D yet)

NewReno Modification
http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-0
1.txt
Action: need WG to read/discuss
        presentation given, but WG list not yet polled for adoption

--
Wes Eddy
MTI Systems

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 23 Nov 2009 12:17:30 -0600

draft-touch-tcp-ao-nat should definitely be on the list;
thanks for the reminder :).

So far, there have been a couple of people that said they'd
support this as part of AO, but not very many.  I haven't
seen anything indicating there are people against it yet
either ... it would be good to hear what more people think
about this as part of the AO WGLC that's in-progress.  If
there's reasonable support, it sounds like Joe is willing
to roll it into the AO draft after WGLC.

--
Wes Eddy
MTI Systems

>From: Gregory Lebovitz [mailto:[email-masked]]
>Sent: Tuesday, November 17, 2009 4:54 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Joe Touch
>Cc: [email-masked]
>Subject: Re: [tcpm] working group status 11/17/09
>
>AEROSPACE CORP] <[email-masked]> wrote:
>
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 23 Nov 2009 20:50:37 +0200

Hi,

without wearing any hats: if it can be added very quickly, i.e., O(days), I'd be mildly in favor. Otherwise, let's just ship what we have now.

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Nov 2009 10:56:33 -0800

Lars Eggert wrote:
> Hi,
> 
> without wearing any hats: if it can be added very quickly, i.e.,
> O(days), I'd be mildly in favor. Otherwise, let's just ship what we have
> now.

Once/if I get a go-ahead, that's all it'd take. There isn't much to it.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Mon, 23 Nov 2009 19:48:56 -0800

<snip>
>        presentation given in Stockholm

An update on this topic: (my original presentation can be found at
http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf)

After some long off-list discussion between Mark Allman and I on
many gory details, we have agreed on the basic reduction of the
initRTO from 3secs to 1sec, only during 3WHS, only ONCE and
exponentially backed off from there. I hereby request this proposal
to be adopted as a WG item. Please let me know what's needed for
this request to be considered. Mark doesn't seem to think a
separate document is needed. Instead a rev (whatever that means)
to RFC2988 may suffice.

Separately I'd like to propose a moderate increase of the initcwnd
from what is specified in RFC3390 to ~15KB, or 10 segments for
IP/Ethernet.

I understand how to speed up TCP's slow start has been an area of
active research, with many proposals on the table (jump/quick/swift/
fast starts,..., etc). But none of the proposals seems ready to go
forward to become an IETF standard anytime soon. (Some require
router support hence are pretty much out of the question for the
public Internet in the foreseeable future).

In order to better take advantage of today's much faster Internet
sooner, a moderate increase of initcwnd seems a good interim
solution. I will send out more details later. In the mean time if
anyone has an opinion on this please feel free to share.

Jerry

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Nov 2009 09:43:39 -0800

Hi, Jerry,

Jerry Chu wrote:
...
> from what is specified in RFC3390 to ~15KB, or 10 segments for

The jump from 1 segment to 4KB took quite a bit of analysis, even though
the basis of the change had been widely deployed as an implementation bug.

I suspect it would take similar analysis to ensure that this would be
safe today, including the effect on home gateways, PDAs, etc.

You are also possibly talking about 30 segments, until path MTU
discovery kicks in. So you're going from 4K or 4 segments (whichever is
smaller) to 15K or ?? segments (10? 30?).

Granted this may already be the common case for persistent connections
going active after draining the data, but it's not clear that such
behavior dominates Internet traffic to a point that the current
operational evidence can be used to validate that this is safe.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 24 Nov 2009 11:55:33 -0600

Hi Jerry.  The way we update RFCs is to write more RFCs :).

In the case of the modifications you're talking about, I'm
not sure if we really want to actually update the standards-
track documents or simply write an Experimental document on
parameter tuning.  Given the subject matter, even an
Experimental RFC may take some time and debate to arrive at.

In either case, I think the starting point is to write an
Internet-Draft that describes and discusses the set of
changes in sufficient detail, and then we can poll this
working group on whether or not to adopt one or more work
items for either Experimental or updates to the standards-
track.

Information on writing and submitting Internet-Drafts is on
the IETF webpage here:
http://www.ietf.org/id-info/

--
Wes Eddy
MTI Systems

>From: Jerry Chu [mailto:[email-masked]]
>Sent: Monday, November 23, 2009 10:49 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>Cc: [email-masked]

---

From: Jerry Chu <[email-masked]>
Date: Tue, 24 Nov 2009 18:24:44 -0800

Hi Joe,

On Tue, Nov 24, 2009 at 9:43 AM, Joe Touch <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Jerry,
>
> Jerry Chu wrote:
> ...

Understood. (Actually I was involved in the effort to up initcwnd from 1
to 2 in the late 90' when Solaris' SPECWEB numbers blew up on our face
due to the extended delay between Windows clients' delayed acks and
Solaris servers' initcwnd of 1.)

My hope this time is that, rather than relying extensively on simulations, we
can leverage Google's vast network reach and determination to "make the web
faster" (see http://code.google.com/speed/)  to collect data from real
experiments to better understand and devise ways to mitigate the negative
impact, if any, from increasing initcwnd.

> smaller) to 15K or ?? segments (10? 30?).

We can work out the exact formula and put a cap on # of segments (e.g., 10).
We would prefer to go higher than 10 but at this moment we still don't
fully understand the negative impact (although small) to warrant the risk.
OTOH we felt 6 or lower is too small to worth the effort. 10 may be a good
balance between benefit vs risk.

> operational evidence can be used to validate that this is safe.

I think a greater problem is web browser's increasing use of more concurrent
connections (I heard IE8 just up the # of concurrent connections per domain
from 2 to 6), partly to circumvent the small initcwnd each TCP connection
gets. To me this alleviates to some extent my own concern of a larger
initcwnd. But it also speaks to the failure of this community to address the
issue (or at least the perception that initcwnd is too small) sooner to
prevent this bad practice from the browser vendors.

Jerry

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksMG0oACgkQE5f5cImnZrv7VwCfWgK4n0yOxFoIwbsBfmKx9pZU
> 9IgAn3wH6mX26Jn6EPjaUz1J838wT8aw
> =HnjU
> -----END PGP SIGNATURE-----
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Nov 2009 21:20:42 -0800

Hi, Jerry,

Jerry Chu wrote:
...
...
> impact, if any, from increasing initcwnd.

Experiments are useful. They are also repeatable. To the extent that
real measurements can be used, that's better than simulations.

However, real measurements will probably also show that simultaneous
open never happens, and that more than a few TCP states are never
entered. That's not sufficient to assert safety of a deployed modification.

...
> prevent this bad practice from the browser vendors.

Well, it could also be that "bad coding expands to find all leaks".
I.e., just because there's another way of doing something, doesn't make
either way appropriate. We've known about burst-after-idle for a number
of years now, and haven't gotten around to fixing that hole. If we did,
the incentive to using multiple connections to get around small initcwnd
would diminish as well.

There's plenty of useful work to do...

Joe

---

From: Jerry Chu <[email-masked]>
Date: Tue, 24 Nov 2009 22:05:45 -0800

> entered. That's not sufficient to assert safety of a deployed modification.

Correct in general but hopefully protocol correctness won't be an issue
here,
or if still is can most likely be understood or thought up
deterministically.

What's hard in the real, passive measurements that we've conducted is that
the visibility into what really happened in the network is extremely
limited. E.g.,
we could not accurately characterize those cases where an increased initcwnd
is hurting, not by RTT, BDP, or measured b/w, which we typically use to
identify "slow links". My guess is the last hop/access router buffer sizes
may
be the determining factor. But passive measurements just don't give us any
visibility into that.

> of years now, and haven't gotten around to fixing that hole. If we did,

Hmm, I thought all stacks (or at least the two I've worked on) have
slow-start
-after-idle enabled by default...

> There's plenty of useful work to do...

Sure there is.

Jerry

> iEYEARECAAYFAksMvqkACgkQE5f5cImnZrtd2wCgwvnKLSY4kdluDV76TU+dWtAV
> Cy8An0YW9HJ39mEMigp2jmRA+sAZn9Ks
> =LkZy

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 25 Nov 2009 14:36:32 -0000

Hi Jerry,

Have you though about the implications of increasing initcwnd to a 
level, which exceeds the buffering capacity of your L2 devices? 
I have observed hosts, which can repeatedly cause heavy packet loss 
due to droptail in a L2 switch, even with a burst size of as little 
as 4-6 frames... These hosts are simply capable of wirespeed sending, 
while the L2 switch is not (or, a common downstream link is slightly 
saturated).

L2 boxes don't seem to feature that much buffering (ie. 40 frames), 
thus will enhance the negative effects of any packet burst. (When the 
L2 buffers are full, and a new session bursts 15+ frames all at once 
into the L2 box.). 

IMHO, some basic pacing should be made mandatory when cwnd is mostly 
empty, to break bursts and deal with slower-than-wirespeed L2 devices 
in the path...

(Tweaking the IFG, or doing some multiplexing with other streams 
right at the sender side, might work - but this requires a lower layer
entity to perform that, not TCP all by itself... You might even argue,
that this is an implementation specific tweak, rather than a TCP 
algrithm all along.

Just my 0.02 EUR.

Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support 
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com 
Franz-Klein-Gasse 5
1190 Wien 

> Sent: Mittwoch, 25. November 2009 03:25
> To: Joe Touch
> Cc: [email-masked]
> > The jump from 1 segment to 4KB took quite a bit of analysis, even 
> > though the basis of the change had been widely deployed as 
> an implementation bug.
> >
> Understood. (Actually I was involved in the effort to up 
> initcwnd from 1 to 2 in the late 90' when Solaris' SPECWEB 
> numbers blew up on our face due to the extended delay between 
> Windows clients' delayed acks and Solaris servers' initcwnd of 1.)
> 
> My hope this time is that, rather than relying extensively on 
> simulations, we can leverage Google's vast network reach and 
> determination to "make the web faster" (see 
> http://code.google.com/speed/)  to collect data from real 
> experiments to better understand and devise ways to mitigate 
> the negative impact, if any, from increasing initcwnd.
> 
> >
> > discovery kicks in. So you're going from 4K or 4 segments 
> (whichever 
> > is
> We would prefer to go higher than 10 but at this moment we 
> still don't fully understand the negative impact (although 
> small) to warrant the risk.
> OTOH we felt 6 or lower is too small to worth the effort. 10 
> may be a good balance between benefit vs risk.
> 
> >
> I think a greater problem is web browser's increasing use of 
> more concurrent connections (I heard IE8 just up the # of 
> concurrent connections per domain from 2 to 6), partly to 
> circumvent the small initcwnd each TCP connection gets. To me 
> this alleviates to some extent my own concern of a larger 
> initcwnd. But it also speaks to the failure of this community 
> to address the issue (or at least the perception that 
> initcwnd is too small) sooner to prevent this bad practice 
> from the browser vendors.
> 
> Jerry
> 
> >
> > Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Nov 2009 10:53:22 -0800

Jerry Chu wrote:
...
> slow-start-after-idle enabled by default...

See:

John Heidemann, Katia Obraczka, and Joe Touch, "Modeling the Performance
of HTTP Over Several Transport Protocols" IEEE/ACM Transactions on
Networking, V5, N5, Oct. 1997, pp.616-630.

After idle, the client sends a short GET out fast even with slow-start.

The server receives the GET, thinks that "time since last received"
defines idle, rather than "time since last sent" as it should be. This
is addressed in the paper.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Wed, 25 Nov 2009 11:55:57 -0800

Hi Richard,

> while the L2 switch is not (or, a common downstream link is slightly

Yes, we suspect the limited edge routers/access-links/wireless-gateways
buffer space, rather than congestion collapse to be the main risk a larger
initcwnd may introduce because the former causes pkts to be dropped
hence negatively impacting performance whereas congestion avoidance
remains intact making the latter unlikely to happen, Unfortunately we have
not been able to confirm this due to the limitation of our passive
measurements as I mentioned earlier.

What will be interesting to know is the distribution of the above mentioned
buffer sizes in today's Internet. This will help in answering questions like
what's the percentage of users that might be affected negatively. If the
percentage is not negligible, how much impact (e.g., just one lost event at
the beginning of a TCP connection?), is there any way to mitigate the
impact,..., etc.

Ultimately we may have to face the choice - does it make sense to slow
down the vast majority of the Internet users just to avoid any negative impact
to a small percentage of users?

> empty, to break bursts and deal with slower-than-wirespeed L2 devices

Yes pacing is one solution to avoid the burst and is required by all the
jump/quick/swift/fast start proposals. Personally I'd prefer to avoid making
it a requirement for initcwnd of 10 in order to keep the change simple.
The hope is we don't need to go that far unless initcwnd is changed
to a much larger size (e.g., > 16).

Jerry