Subject: Intermediary-assisted retransmission at layer(s) below 3.

From: Roberto Peon <[email-masked]>
Date: Wed, 30 Aug 2017 20:02:59 +0000

A recent email from Christian Huitema about congestion related things got me wondering if we’d discussed signaling to intermediaries about whether or not they’re supposed to help with retransmission. Has that discussion happened yet?

-=R
(Roberto Peon for those who don’t know yet ;) )

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 30 Aug 2017 22:52:33 -0700

Welcome back from the dead, Roberto! You seem to have woken up in the wrong
company, but still ...

I don't think we discussed this specific issue, but I believe (and the
chairs can correct me if I'm wrong) that the general issue of explicit
signaling to intermediaries is largely out of scope for the wg. The wg's
scope is limited to "consider the impact of the protocol on network
management practices", largely because parallel efforts (SPUD, then PLUS)
were going after the signaling to intermediaries in a more general fashion,
and partly because this discussion ends up being a massive rat-hole of
never-ending agony. Again, my opinion, others may disagree.

That said, there have been a slate of recent discussions on exposing some
amount of connection info to middleboxes, particularly to allow them to
passively measure RTT, but that's not the issue you asked about.

On Wed, Aug 30, 2017 at 1:02 PM, Roberto Peon <[email-masked]> wrote:

> A recent email from Christian Huitema about congestion related things got
> me wondering if we’d discussed signaling to intermediaries about whether or
> not they’re supposed to help with retransmission. Has that discussion
> happened yet?
>
>
>
> -=R
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 Aug 2017 16:08:55 +1000

On 31 Aug 2017, at 3:52 pm, Jana Iyengar <[email-masked]> wrote:
> 
> Welcome back from the dead, Roberto! You seem to have woken up in the wrong company, but still ...
> 
> I don't think we discussed this specific issue, but I believe (and the chairs can correct me if I'm wrong) that the general issue of explicit signaling to intermediaries is largely out of scope for the wg. The wg's scope is limited to "consider the impact of the protocol on network management practices", largely because parallel efforts (SPUD, then PLUS) were going after the signaling to intermediaries in a more general fashion, and partly because this discussion ends up being a massive rat-hole of never-ending agony. Again, my opinion, others may disagree.
> 
> That said, there have been a slate of recent discussions on exposing some amount of connection info to middleboxes, particularly to allow them to passively measure RTT, but that's not the issue you asked about.

I think that's a bit strong. The only things explicitly called out of scope by the charter:

"""
Extensions that will support partial reliability, and negotiation 
and use of Forward Error Correction schemes, are out of scope in 
this version of the working group charter.
"""

There are of course numerous rat holes in this area, but they have more to do with extensible frameworks for communicating with middleboxes, as well as things that look like means of leaking information to them (or allowing them to exert undue control). I don't know whether configuring lower-layer "help" with things like like retransmission / FEC falls into them, so it seems premature to rule them out at this stage (although we do have to manage the discussion; we have a lot of ground to cover).

Discussion of measurement of RTT and friends by middleboxen *is* off the table until we hear back from the Design Team in Singapore.

Welcome back to the circus, Roberto. If you want to open an issue / make a proposal here, please feel free; I don't think we have anything that covers it. 

FYI, if you haven't seen it already, this might help:
  https://github.com/quicwg/base-drafts/projects

Then again, it might scare you away.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: joel jaeggli <[email-masked]>
Date: Wed, 30 Aug 2017 23:54:21 -0700

On 8/30/17 22:52, Jana Iyengar wrote:
> management practices", largely because parallel efforts (SPUD, then
> PLUS) were going after the signaling to intermediaries in a more general
> fashion, and partly because this discussion ends up being a massive
> rat-hole of never-ending agony. Again, my opinion, others may disagree.

As someone who encouraged that language to be included, my concerns were
that the properties of a "flow" not become so opaque that hashing became
ineffective both on ECMP Paths orLAG bundles, and similarly that ipfix
would still be able to distinguish between flows. State-awareness with
respect to the forwarding path is my view incredibly expensive and not
desirable any time significant scale is involved.

> That said, there have been a slate of recent discussions on exposing
> some amount of connection info to middleboxes, particularly to allow
> them to passively measure RTT, but that's not the issue you asked about.
> 
> 
> 
> On Wed, Aug 30, 2017 at 1:02 PM, Roberto Peon <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     A recent email from Christian Huitema about congestion related
>     things got me wondering if we’d discussed signaling to
>     intermediaries about whether or not they’re supposed to help with
>     retransmission. Has that discussion happened yet?____
> 
>     __ __
> 
>     -=R____
> 
>     (Roberto Peon for those who don’t know yet ;) )____
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 31 Aug 2017 05:50:15 -0500

As the responsible AD for QUIC ...

On Aug 31, 2017 01:09, "Mark Nottingham" <[email-masked]> wrote:

I think that's a bit strong. The only things explicitly called out of scope
by the charter:

"""

There are of course numerous rat holes in this area, but they have more to
do with extensible frameworks for communicating with middleboxes, as well
as things that look like means of leaking information to them (or allowing
them to exert undue control). I don't know whether configuring lower-layer
"help" with things like like retransmission / FEC falls into them, so it
seems premature to rule them out at this stage (although we do have to
manage the discussion; we have a lot of ground to cover).

One point to remember is that I haven't seen a lot of explanation as to why
we'd want middleboxes to add support for something QUIC-specific, much less
HTTP2/QUIC- specific.

Why middleboxes would want to do that is also a mystery to me, but not one
that matters until I hear why we would want them to do that.

I have some willingness to listen to proposals about middleboxes(*) that
are targeted more broadly, but significantly less willingness to listen to
them in the QUIC working group.

If this topic matters to people, I note that the BOF proposal cutoff for
IETF 100 is more than a month out, although it's best not to wait until the
last minute.

https://ietf.org/meeting/important-dates.html#ietf100

Thanks,

Spencer

(*) who is the responsible AD for STUN and TURN protocol work in TRAM, so
can imagine middleboxes without bursting into flames, but that's not in the
QUIC working group, either

Discussion of measurement of RTT and friends by middleboxen *is* off the
table until we hear back from the Design Team in Singapore.

Welcome back to the circus, Roberto. If you want to open an issue / make a
proposal here, please feel free; I don't think we have anything that covers
it.

Cheers,