Subject: [Stackevo] Indefinite coexistence as an end state

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 14:53:16 +1100

The notion of transition in earlier versions of the
protocol-transitions doc was implicitly quite hermetic.  You made the
new protocol, deployed it (with some effort) and the old one went
away.

Thanks to recent changes, this is now much more nuanced.  It
identifies new protocols, replacement protocols (and versions), and
protocol removals as all requiring this sort of attention.

My experience with HTTP is that the hope of ever effecting a removal
is so laughable that no one ever seriously considers it.  Thus, I am
proposing text to add to the section on "coexistence" that recognizes
this point.

   https://github.com/dthaler/ietf/pull/6

I think that this goes some way to addressing one of Eliot's earlier
concerns about HTTP.  That is that new versions maybe did or didn't
consider some of the vast array of use cases that the protocol was
being put to.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Feb 2017 13:36:57 +0000

Hi Martin,

> On Feb 21, 2017, at 10:53 PM, Martin Thomson <[email-masked]> wrote:
> 
>   https://github.com/dthaler/ietf/pull/6 <https://github.com/dthaler/ietf/pull/6>

I agree with the essence of your text but I fail to see the difference between the HTTP2/1.1 case and the IPv6/v4 case. In both cases, the newer protocol will eventually overtake the older protocol but it is going to be a slow and long drawn out process. Is there something I am missing?

Thanks
Suresh

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 22 Feb 2017 14:44:32 +0100

I think it's a question of intent, not of effect: the goal of IPv6 was to replace IPv4 in all (Internet-connected) addressing contexts, whereas the goal of H2 is not necessarily to replace HTTP/1.1 for all of HTTP/1.1's applications.

The effect is largely the same, though, since IPv6's original goal is no longer attainable. It's all a matter of when you get to declare victory. Indeed, one could say that the economics and the RIR policies currently in place are driving toward a different goal: to replace to the extent that the market cost of a v4 address in the global addressing context approaches zero, which will probably happen one day.

Cheers,

Brian

> On 22 Feb 2017, at 14:36, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Martin,
> 
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 07:27:41 +1100

> I think it's a question of intent, not of effect: the goal of IPv6 was to replace IPv4 in all (Internet-connected) addressing contexts, whereas the goal of H2 is not necessarily to replace HTTP/1.1…

Yep.

> The effect is largely the same, though, since IPv6's original goal is no longer attainable. It's all a matter of when you get to declare victory. Indeed, one could say that the economics and the RI…

This is the sort of goal I imagine you might realistically have for
v6.  The other would be that you could reasonably expect to be able to
use v6 only and reach any host.  That might happen a little earlier.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 23 Feb 2017 06:01:09 +0000

Hi Martin/Brian,

> On Feb 22, 2017, at 3:27 PM, Martin Thomson <[email-masked]> wrote:
> 

Right. But what does this distinction mean in practice? If the new protocol is aimed at replacing the old one, what does it need to do differently (or should it even try to replace the old one)? Should this draft provide some advice?

Thanks
Suresh

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 22:11:29 +1100

The PR says:
>Such a protocol might only aim to
> address a subset of the use cases for which an original is used.

Thus for some use cases, the replacement might be effective, but
unless all of the use cases can be accommodated, the old protocol will
remain.

I don't think that we need to say anything about this more than that.
If the new protocol is an imperfectly complete replacement and that is
intentional, that's cool.

Do you think that we need to explicitly say that an unintentionally
incomplete replacement is a serious impediment to being able to
decommission an old protocol?  It seems pretty obvious to me, and the
NAT-PT example early on establishes this as a contributing factor in
IPv6 transition delays.  It might not hurt to say it directly though
if that is what you are driving at.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Feb 2017 15:13:36 +0100

Hi,

Just a few more thoughts:

> unless all of the use cases can be accommodated, the old protocol will

I wonder if it helps to think about protocol P as distinct Protocols
P_1-n , given n different use cases, where the end applications in each
of those cases are distinct.  HTTP has (to borrow a technical term) a
gazillion of these.  A new protocol needn't, then, attempt to substitute
itself for all n, but just some particular P_i .
> intentional, that's cool.
[oops] ;-)

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Feb 2017 09:31:17 +1100

On 24 February 2017 at 01:13, Eliot Lear <[email-masked]> wrote:
> I wonder if it helps to think about protocol P as distinct Protocols P1-n,
> given n different use cases, where the end applications in each of those
> cases are distinct.  HTTP has (to borrow a technical term) a gazillion of
> these.  A new protocol needn't, then, attempt to substitute itself for all
> n, but just some particular Pi.

That's the idea.  If I failed to convey this in my pull request and it
can somehow be make clearer/tighter, feel free to suggest some text.

FWIW, we didn't explicitly aim to *exclude* use cases with HTTP/2, but
as you say the actual use of the protocol is insanely diverse.  There
isn't much point in setting yourself up for failure by attempting to
hit them all.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Feb 2017 22:08:47 -0600

I think this is the right place for me to reply in this thread ...

On Feb 22, 2017 14:27, "Martin Thomson" <[email-masked]> wrote:

On 23 February 2017 at 00:44, Brian Trammell (IETF) <[email-masked]>
wrote:
> I think it's a question of intent, not of effect: the goal of IPv6 was to
replace IPv4 in all (Internet-connected) addressing contexts, whereas the
goal of H2 is not necessarily to replace HTTP/1.1 for all of HTTP/1.1's
applications.

Yep.

> The effect is largely the same, though, since IPv6's original goal is no
longer attainable. It's all a matter of when you get to declare victory.
Indeed, one could say that the economics and the RIR policies currently in
place are driving toward a different goal: to replace to the extent that
the market cost of a v4 address in the global addressing context approaches
zero, which will probably happen one day.

I've been involved in a few "doomed to provide a fallback forever"
discussions on applications that use QUIC, except when QUIC isn't working
for them, so they fall back to TCP for transport.

Have people thought about this in enough detail to know whether the current
draft text covers this?

If not, I'm OK with that, but I am curious.

Thanks,

Spencer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Feb 2017 15:25:49 +1100

> Have people thought about this in enough detail to know whether the current

Mirja and Brian have added a good bit of text in their applicability
statement.  There are open issues regarding fallback in the main
documents, which probably need some treatment of fallback.  But that's
a discussion that belongs over there.

You might be interested in the discussion about greasing - that is,
safeguarding extensibility points aggressively by using them - and its
interactions with alternative services and fallback generally, which
tends to hide certain classes of failure that we might prefer be made
more visible.  We're still working through the details there.
Synopsis: where you are forced to be lenient on errors, you lose some
valuable signals about the existence of errors, some of which you
might have preferred to treat more harshly.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 24 Feb 2017 10:31:52 -0600

Hi, Martin,

On Feb 23, 2017 22:25, "Martin Thomson" <[email-masked]> wrote:

I'm sorry I wasn't clear - I was asking if perpetual fallback was a topic
for discussion in
https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/ yet :-) ...

Thanks,

Spencer