Subject: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Nov 2015 12:18:34 +0100

Hi all,

I just watched the video of TCPM and noticed a minor confusion at the end about what the plan really is - because draft-welzl-tcpm-tcb-sharing just contains a table contrasting RFC 2140 to implementations, and are we aiming at Informational or a recommendation?

Our plan is to update RFC 2140 to bring it in line with today's reality - what is currently implemented. I think Informational is still fine as status (but open to debate if people feel otherwise).

Why didn't we write RFC2140bis but a separate document? Because one of the chairs suggested this as a way forward, rather than doing a full first version of RFC2140bis, given that we believed that just showing this table and opening it for discussion is the best way to get this started.

Cheers,
Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 5 Nov 2015 10:54:26 -0800

Some data points to the Linux implementation: we've found it more harmful
than useful, and have disabled it at Google (internal/external) for years.

Externally: IP no longer serves a good index. e.g., DHCP, NAT. Therefore
most if not all metrics are brittle.
Even for places where IP indexing still works: reusing ssthresh from TCP
just recovered from timeout will force the new TCP to exit slow start right
away

On Thu, Nov 5, 2015 at 3:18 AM, Michael Welzl <[email-masked]> wrote:

> Hi all,
>
> I just watched the video of TCPM and noticed a minor confusion at the end
> about what the plan really is - because draft-welzl-tcpm-tcb-sharing just
> contains a table contrasting RFC 2140 to implementations, and are we aiming
> at Informational or a recommendation?
>
> Our plan is to update RFC 2140 to bring it in line with today's reality -
> what is currently implemented. I think Informational is still fine as
> status (but open to debate if people feel otherwise).
>
> Why didn't we write RFC2140bis but a separate document? Because one of the
> chairs suggested this as a way forward, rather than doing a full first
> version of RFC2140bis, given that we believed that just showing this table
> and opening it for discussion is the best way to get this started.
>
> Cheers,
> Michael
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Nov 2015 13:50:31 -0800

On 11/5/2015 10:54 AM, Yuchung Cheng wrote:
...
> Externally: IP no longer serves a good index. e.g., DHCP, NAT.

That's not necessarily true. In both cases, the machines that might
share an IP address often share the dominant aspects of their network
paths - delay, loss, max bandwidth, etc.

Additionally, the shared information is used only for connection
initialization. That shared information doesn't have to be accurate,
only somewhat better than the current default initial values.

> Therefore
> just recovered from timeout will force the new TCP to exit slow start
> right away

Agreed; that's one of the issues we're hoping to learn more about and
include in the update. E.g., SSTHRESH from steady-state is a better
predictor of future behavior than an immediate anomalous value - low or
high. That's true for most parameters.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 5 Nov 2015 22:51:05 +0000

> I just watched the video of TCPM and noticed a minor confusion at the
> end about what the plan really is - because draft-welzl-tcpm-tcb-
> sharing just contains a table contrasting RFC 2140 to implementations,
> and are we aiming at Informational or a recommendation?
> 
> Our plan is to update RFC 2140 to bring it in line with today's reality
> - what is currently implemented. I think Informational is still fine as
> Why didn't we write RFC2140bis but a separate document? Because one of
> the chairs suggested this as a way forward, rather than doing a full
> first version of RFC2140bis, given that we believed that just showing
> this table and opening it for discussion is the best way to get this
> started.

And this chair somehow believes that having a very short I-D is much better than a presentation w/o any I-D...

Michael

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 6 Nov 2015 10:08:17 +0900

Yep, I was only interested to hear about your future plans about the document and rfc2140bis work in general. Understood that the current version was mainly to support the discussion, which is good.

- Pasi

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 5 Nov 2015 20:58:49 -0800

> only somewhat better than the current default initial values.
Intuitively yes. But our tests show little difference in terms of
latency, loss rate, etc with or without the Linux IP metrics cache.
And disabling not only save cache write/read but also skip the pathological
cases.

Today a phone can have multiple public IP addresses and an IP address
can be used for multiple phones simultaneously (with different ports).
The RTT, link
quality, and BW can all be very different. This makes IP a less
reliable index for server cache or CB sharing even only for seeding phase.

I am not claiming it's universally useless. I am presenting a data
point primarily on servers.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 6 Nov 2015 08:57:23 +0100

> On 06 Nov 2015, at 05:58, Yuchung Cheng <[email-masked]> wrote:
> 

Sounds like at least some text explaining these potential problems with relying on the IP address is needed for the planned RFC2140bis. Which I think is quite appropriate. Thanks for the data point!

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 6 Nov 2015 11:04:59 -0800

FWIW, we also need to differentiate the impact of these issues on
temporal vs. ensemble sharing.

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 6 Nov 2015 11:33:17 -0800

> temporal vs. ensemble sharing.
I also think it's more useful to analyze the impact of existing
implementations, instead of documenting code. the metrics cache isn't hard
to understand at all in Linux and the code changes over time. What we
document today can be obsolete tomorrow, so in the end one still need to
read the code to get the latest info. In other word I think this draft is a
waste of time honestly speaking.

> > Sounds like at least some text explaining these potential problems with
> relying on the IP address is needed for the planned RFC2140bis. Which I
> think is quite appropriate. Thanks for the data point!
> >
> > Cheers,
> > Michael
> >
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 6 Nov 2015 12:16:14 -0800

On 11/6/2015 11:33 AM, Yuchung Cheng wrote:
> 
> 
> On Fri, Nov 6, 2015 at 11:04 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> implementations, instead of documenting code.

Right; this is the IETF, and code documentation isn't the goal.

> the metrics cache isn't
> hard to understand at all in Linux and the code changes over time. What
> we document today can be obsolete tomorrow, so in the end one still need
> to read the code to get the latest info. In other word I think this
> draft is a waste of time honestly speaking.

The draft is the starting point; it is intended to gather information
about the impact of existing implementations, exactly as you describe.

Joe

>     >> On 06 Nov 2015, at 05:58, Yuchung Cheng <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >> On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>>
>     >>>
>     > Sounds like at least some text explaining these potential problems
>     with relying on the IP address is needed for the planned RFC2140bis.
>     Which I think is quite appropriate. Thanks for the data point!
>     >
>     > Cheers,
>     > Michael
>     >
> 
>