Subject: [v6ops] Fwd: New Version Notification for draft-baker-v6ops-session-start-time-00

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 15:33:20 -0400

If I get enough people telling me they agree with this, I'll send it off to random ADs and WG Chairs as an internet draft and ask for time to discuss it in their working groups in Beijing, and not occupy v6ops time with it. If you don't comment, I'll bore you to tears with it in the meeting :-)

It's short. The important bits fit on a bit over a page. The important references are:
   
http://www.ietf.org/rfc/rfc5461.txt
5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. 
     (Format: TXT=31749 bytes) (Status: INFORMATIONAL)

and

http://tools.ietf.org/id/draft-wing-http-new-tech
     Wing, D., Yourtchenko, A., and P. Natarajan, "Happy
     Eyeballs: Trending Towards Success (IPv6 and SCTP)",
     August 2010.

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: October 6, 2010 3:18:04 PM EDT
> To: [email-masked]
> Subject: New Version Notification for draft-baker-v6ops-session-start-time-00 
> 
> 
> A new version of I-D, draft-baker-v6ops-session-start-time-00.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
> 
> Filename:	 draft-baker-v6ops-session-start-time
> Revision:	 00
> Title:		 Opening TCP Sessions in Complex Environments
> Creation_date:	 2010-10-06
> WG ID:		 Independent Submission
> Number_of_pages: 5
> 
> Abstract:
> A barrier to the deployment of IPv6 is the amount of time it takes to
> open a session using common transport APIs.  This note addresses
> issues and requests solutions that may respond to them.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 06 Oct 2010 16:25:22 -0400

IMHO -> TSVAREA.  It's not about IPv6 or even IP, it's about
establishing transport connections.

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 06 Oct 2010 17:54:30 -0400

It seems prudent to post this draft as a question to intarea and 
tsvarea as suggested, and see what area would take it up.  Also apparea 
where Happy Eyeballs is under discussion.  Seems that tsvarea (tcpm) 
would be appropriate forum to discuss taking RFC 5461 approach to standard.

On 10/6/2010 3:33 PM, Fred Baker wrote:
>> From: IETF I-D Submission Tool<[email-masked]>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 2010 11:31:39 +1300

I need to point out that there is closely related standards text,
code, and experience in REAP (RFC5534). Although REAP was designed
as part of shim6, it's relatively separable if need be.

It also scales quite well, and tells us something about how long
trying out alternate paths will take in practice. The following
paper covers this, as well as how much is to be gained by
trying out alternate paths in parallel (see the section on
sending initial probes concurrently).
http://www.cs.auckland.ac.nz/~brian/iccnt2010_reap.pdf
(from ICCNT 2010 conference).

Regards
   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Oct 2010 18:53:33 -0300

Hi, Fred,

FWIW, I agree with this.

Thanks,
Fernando

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 20:36:32 -0400

Thanks.

---

From: Scott Brim <[email-masked]>
Date: Wed, 06 Oct 2010 22:23:50 -0400

Brian E Carpenter allegedly wrote on 10/06/2010 18:31 EDT:
> code, and experience in REAP (RFC5534). 

(getting out of scope for v6ops but since we're here ...)

REAP is focused on failure recovery and parsimonious probing, while the
happy eyeballs issue is configuring and caching connectivity results at
multiple layers (v4, v6, different transport protocols) so the endpoints
can quickly establish a connection that is likely to be useful.

> Although REAP was designed

Good because Shim6 doesn't look like it's taking over the Internet :-p

> trying out alternate paths will take in practice.

I don't recall if you saw my slides from Dagstuhl in early 2009, but
everything you can accomplish with REAP and alternate paths you can do
at least as well with concurrent multipath transport (SCTP, MPTCP).

See you soon ... Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 2010 15:35:01 +1300

> can quickly establish a connection that is likely to be useful.

I understand. But it is entirely possible that a REAP-like process spanning
v4 and v6 would be a method of achieving happy eyeballs for all applications
in one go, without any API impact or needing to touch the transport layer.

As the simulation shows, moving from sequential probing to simultaneous
probing does improve (re)connect time, but not so much as you might
expect.

> at least as well with concurrent multipath transport (SCTP, MPTCP).

Yes, of course these things are equivalent at some level. shim6 was
invented specifically to be invisible to widely used transport layers
such as TCP and UDP. It is an exercise for the reader to decide whether
shim6, SCTP or MPTCP has the best chance of taking over the Internet.

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Oct 2010 22:59:54 -0400

> probing does improve (re)connect time, but not so much as you might

As I said in private email, I think they are looking at different problems. 

If I have N*M address pairs (if I am connecting to some other system, I have N addresses and it has M), I can write a relatively simple equation for the amount of time it will take to set up a connection. Let's imagine I know the ping RTT for each pair, and let's call that value RTTij for i in 1..N and j in 1..M. If I send all SYNs simultaneously (and ignore queuing effects), the amount of time it will take to open one of the sessions is the least value in {RTTij | i in 1..N, j in 1..M}. If I start them sequentially and the inter-start time is P, then in the worst case the time to open a session is (N*M-1)*P + RTTnm; the average is probably (N*M-1)*P/2 + RTT[N/2][M/2], and the least is RTT[1][1].

Now, consider the value of P. In most present applications' use of the Socket API, it opens a socket, attempts to connect, waits until the connect fails, and then tries the next. That puts P in the ballpark of 2-3 seconds. What Happy Eyeballs suggests is to arbitrarily limit P to a magic number - 50 ms being recommended - and start new sessions in parallel.

For any positive value of N and M, (N*M-1)*3 seconds + a constant is greater than (N*M-1)*0.050 seconds + a constant, roughly 60 times as large.

I think what your simulation is measuring is the interference of the REAP protocol, which if there are more than 10 address pairs your article says measurably impedes the traffic it is protecting, with the traffic it is protecting.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 2010 16:58:02 +1300

> Now, consider the value of P. In most present applications' use of the Socket API, it opens a socket, attempts to connect, waits until the connect fails, and then tries the next. That puts P in the…

Yes, and that would in effect cut the tail off a long tail distribution. Of course,
the value of 50ms could be tuned experimentally.

> I think what your simulation is measuring is the interference of the REAP protocol, which if there are more than 10 address pairs your article says measurably impedes the traffic it is protecting,…

Correct. Well, in theory, we can simulate anything, I suppose.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Oct 2010 00:29:27 -0400

> the value of 50ms could be tuned experimentally.

IMHO, Happy Eyeballs' 50 ms is a SWAG - a Silly Wild-A$$ed Guess. If I were to make it, I'd make it 10 ms. And someone else would pick pi^3. I think some serious experimentation is in order on that aspect.

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Oct 2010 21:42:07 -0700

> IMHO, Happy Eyeballs' 50 ms is a SWAG - a Silly Wild-A$$ed Guess. If I were to make it, I'd make it 10 ms. And someone else would pick pi^3. I think some serious experimentation is in order on that…

Indeed.

FWIW, I'd choose something on the order of magnitude of 2 or 3 times
the mean or median RTT on the Internet, as measured by CAIDA or
something.

Also, timers on the connect() are one thing, but additional steps need
to be taken by applications in the face of possible pMTUd failures.
I've definitely seen instances where an IPv6 TCP connect happens
plenty fast, but forward progress on, say, an HTTP GET where the
returned page is "large" just hangs.  But that's a slightly different
discussion.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Oct 2010 23:24:52 -0700

> returned page is "large" just hangs.  But that's a slightly different

Significantly different discussion. 

Instead of talking about GETs which can be dismissed ("nyeah, it was
slow, do it again over IPv4 after awhile"), I worry about POSTs hitting
these PMTUD problems, because they could change the state on the server
(partially updating a file, selling stock, ...  who knows what else).

-d

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Oct 2010 10:03:47 +0200

Hi,

On Wed, Oct 06, 2010 at 03:33:20PM -0400, Fred Baker wrote:
> If I get enough people telling me they agree with this, 

*agree*

Gert Doering
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Oct 2010 11:38:58 +1300

Dan,

> From: Dan Wing <[email-masked]>
> Date: Thu, Oct 7, 2010 at 7:24 PM
> Subject: Re: [v6ops] Fwd: New Version Notification
> for	draft-baker-v6ops-session-start-time-00
> To: Erik Kline <[email-masked]>, Fred Baker <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>, Scott Brim
> <[email-masked]>, [email-masked]
> 
> 

And I'm not sure it's relevant to the happy eyeballs model. POST failures,
by definition, arise after you've already made a TCP connection to
the server. A failure to discover a too-small PMTU (or NATs losing state),
may explain them, but those are entirely different problems. The fact
that POST is a broken transaction protocol is unfixable.

    Brian