Subject: Fwd: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

From: Kazuho Oku <[email-masked]>
Date: Fri, 13 Aug 2021 15:14:28 +0900

Hello folks,

Today Jana and I have submitted a tiny I-D called
draft-kazuho-httpbis-selftrace.

The draft specifies a well-known URI to be used for providing a trace of a
particular HTTP/3 connection (e.g., qlog) on that same HTTP/3 connection.

One of the biggest hurdles in analyzing HTTP/3 performance issues is
obtaining traces that show the symptoms. That is because clients being
affected by issues have to coordinate with the server operators to collect
the traces.

This PR solves the problem by defining a well-known URI for serving a trace
to the client on the HTTP connection that the client is using. When a user
sees an issue, they can collect the traces themselves and provide it to the
server operator.

We have already implemented the feature in h2o, and doing so was easy,
assuming that the underlying QUIC stack already defines callbacks for
collecting trace events, see lib/handler/self_trace.c of
https://github.com/h2o/h2o/pull/2765.

We also have a public endpoint; to try it out, first open
https://ora1.kazuhooku.com/test/self-trace/video-only.html (which starts
streaming a video), then open
https://ora1.kazuhooku.com/.well-known/self-trace. While the video is being
served, you would see the trace flowing through the well-known URI.

At the moment, we are using a custom JSON format for the trace, but when
gzip compression is applied on-the-fly, the overhead of sending a trace
alongside ordinary HTTP responses is less than 10%. Therefore, we tend to
believe that this approach would work well in practice.

Please let us know what you think - your feedback is very welcome.

---------- Forwarded message ---------
From: <[email-masked]>
Date: 2021年8月13日(金) 14:53
Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
To: Jana Iyengar <[email-masked]>, Kazuho Oku <[email-masked]>

A new version of I-D, draft-kazuho-httpbis-selftrace-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-httpbis-selftrace
Revision:       00
Title:          Self-Tracing for HTTP
Document date:  2021-08-13
Group:          Individual Submission
Pages:          5
URL:
https://www.ietf.org/archive/id/draft-kazuho-httpbis-selftrace-00.txt
Status:
https://datatracker.ietf.org/doc/draft-kazuho-httpbis-selftrace/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-selftrace

Abstract:
   This document registers a "Well-Known URI" for exposing state of an
   HTTP connection to the peer using formats such as qlog schema [QLOG].

The IETF Secretariat

-- 
Kazuho Oku

---

From: Robin MARX <[email-masked]>
Date: Fri, 13 Aug 2021 18:28:05 +0200

Hello Kazuho,

Thanks a lot for writing this up and sharing it.
This concept has been part of the qlog docs since the very start [1], but
has simultaneously been something that no-one has implemented yet, so it's
good to see a concurrent proposal and an actual POC that seems to work
quite nicely!
I think this capability will be core to allow people to diagnose QUIC in
the wild, as we've seen just this week with some of the problems Wix had to
properly identify H3 vs H2 gains on their Fastly deployment [2].

A couple of questions/remarks:

1) The trace stream currently starts from when the request for the
well-known URL is received, thus missing all events before that (e.g.,
handshake details).
    I understand this is a tradeoff (you don't want to keep full traces for
all connections just in case they are requested), but I feel we might want
a way to indicate at the very start (e.g., transport parameter) that a
trace will be requested so we can request that info as well?

2) There are downsides to loading the trace over the same connection, some
of which you note in the text and in the email (overhead for the "real"
connection). The qlog text allows fetching of traces of connection A over
connection B by CID, but that of course has other tradeoffs.
    I feel your method is probably best, IF we can find a solution for
point 1). e.g., if you don't want to impact real connection, you request
trace at start, let the connection run, and then fetch full trace at the
end instead of streaming during.
    This does introduce some extra (resource exhaustion) attack vectors
that need mitigations etc.

3) Relatedly, your POC seems to assume the browser will have just a single
connection and a trace request in a second tab will auto map to that
connection.
    That works fine for the POC, but for a real deployment that lets
end-users fetch traces, you'd need built-in browser/client support to
select a specific connection / fetch traces for all connections to a given
origin.
     Not a big problem ofc, and things like Chrome's netlog export already
do this, but still a practical hurdle.

4) Any reason in particular you're not streaming qlog? I assume it's
because you don't log qlog directly but instead use a converter and that
converter adds too much overhead to do on the fly?
    Not that it really matters or that I feel we should limit to qlog, but
it does bring up the question of how an automated client setup (e.g., via
WebPageTest-alike tooling) would identify what the server sends back.
    You of course already know this because you made the qlog issue for it
[3], but good to bring it up on the list as well.

5) I wonder if this should be a completely separate document, a separate
document part of the qlog effort, or part of the qlog documents.
    As said in 4), I don't feel this necessarily should be limited to qlog,
but a lot of the privacy issues+mitigations inherent to exposing logs will
be discussed for qlog and should probably be referenced for this approach
as well.
    Currently, you seem to skirt some of this by saying it doesn't matter
because the client is the one requesting the logs, but I don't quite agree
that's enough.
    This could be used to ask end-users to capture a trace of a problematic
connection and upload it for analysis. If the end-user isn't very
technical, they might not know which info they're exposing. Even if they
are, they probably don't want to go through the trouble of sanitizing the
logs themselves.
    Put differently: this should probably either be restricted to expose no
privacy-sensitive info at all (or at least discuss the issues) or allow
explicit selection of a "privacy level" (the approach we'll probably take
with qlog is to define multiple levels of obfuscation/omission for
different use cases).

I am very excited by the proposal and would love for some large deployments
to offer this service.
I feel that wouldn't just be revolutionary to many academic efforts, but
also enable better client-aided debugging and to allow users to assess
bottlenecks in their setups.

With best regards,
Robin

[1]:
https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-00#section-7.2
[2]: https://twitter.com/alonkochba/status/1424403252284694528?s=20
[3]: https://github.com/quicwg/qlog/issues/158

On Fri, 13 Aug 2021 at 08:15, Kazuho Oku <[email-masked]> wrote:

> This PR solves the problem by defining a well-known URI for serving a
> trace to the client on the HTTP connection that the client is using. When a
> user sees an issue, they can collect the traces themselves and provide it
> to the server operator.
>
> https://ora1.kazuhooku.com/.well-known/self-trace. While the video is
> being served, you would see the trace flowing through the well-known URI.
>

-- 

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

*Cellphone *+32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 13 Aug 2021 19:12:44 -0700

Robin,

On the privacy question -- indeed the user doesn't know what info is being
shared but note that this is a server-side log that is being streamed to
the client. This is no different than the server logging it directly. The
primary value here is for a user to log a "problematic" connection, where
otherwise servers in general do log random connections for perf analysis.

This solves a real problem right now for us which is to be able to grab
server-side traces for specific repeatable performance problems on certain
connections. A client can tell us there's a perf issue with a particular
domain, but without much else, we have to try and repro it, and without the
client's setup, we are often unable to easily do this.

With this mechanism, we can ask the reporter to send us a self-trace for
the repeatable issue. This is quite similar to Chrome netlogs (which are
requested from users who report issues,
https://support.google.com/chrome/a/answer/6271171), except that it is
server side logs.

So, we don't stream qlog; the current format is based on what was easiest
for us to do. Importantly, this doc isn't about the format, it's about a
mechanism to spit out logs that are local to a server. We might even want
to send some server infra specific info that we can send as an encrypted
blob in this stream.

I don't think this should be in the qlog doc. Of course there is value in
emitting qlog -- one can build and use standard tools and such around this
if it were to be emitted in qlog format. But I don't see this as a reason
to limit this mechanism to emit only qlog.

- jana

On Fri, Aug 13, 2021 at 9:50 AM Matt Joras <[email-masked]> wrote:

> Happy to see this work! Speaking as an individual:
>
> One limitation of this sort of scheme (HTTP triggering and utilizing the
> same connection) is that it won't be able to capture two classes of issues
> that can be very problematic: handshake setup issues and mid-connection
> "stalling" issues. The former I think it's pretty obvious why, as this
> trace is triggered by an HTTP signal. As an example of the latter, consider
> a bug where the server runs down its flow control or congestion control to
> zero and can't recover. This ends up with the server being perpetually
> blocked from sending anything, and both endpoints idle timing out. If a
> client wants to trigger a trace and reproduce the issue then it will end up
> not getting a trace at all, since the server is stuck. That's not to say
> this kind of tracing isn't useful for other classes of issues, but these
> are two serious ones we've had to diagnose with "out of band"
> non-HTTP-triggered qlogs, and I wonder if we should also explore a
> standardized mechanism for triggering those kind of traces.
>
> Matt
>
> On Fri, Aug 13, 2021 at 12:15 AM Kazuho Oku <[email-masked]> wrote:
>
>> Hello folks,
>>
>> The draft specifies a well-known URI to be used for providing a trace of
>> a particular HTTP/3 connection (e.g., qlog) on that same HTTP/3 connection.
>>

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 13 Aug 2021 19:23:25 -0700

Matt,

Both good points. These are limitations of this approach (and can be noted
in the document), but I don't know how you can get around these issues
using this mechanism.

For the HS issue, Robin suggested using a TP, and while specifying the
mechanism is easy, I'm not sure how useful it will be given that there's no
easy way to trigger that on a browser or web clients.

For CC/FC issues, you could ignore CC for specifically sending a message
that says "my available cwnd is 0", but you can't get around FC, since you
violate FC at the receiver and risk getting the connection closed. While
these  signals are useful, you can also infer them in 2 other ways:
(i) you stopped receiving data and traces. Presumably a client-side trace
can be gathered which should show BLOCKED frames being received.
(ii) it isn't too difficult to see a diminishing cwnd or rwnd in the trace
that has been received prior to getting blocked.

- jana

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Aug 2021 12:43:52 +1000

Hi Kazuho and Jana,

How does an intermediary understand when this request is directed at them? In particular, a CDN or reverse proxy, vs. the origin? Currently, the text says 'When a server receives a GET request at the Self-Trace Well-Known URI...' which includes intermediaries by definition...

>    To prevent this attack, servers SHOULD serve self-trace only when
>    HTTPS is being used.  The assumption here is that when HTTPS is being
>    used, end-clients are directly connected to the server.

I'm not sure that's a reasonable assumption; enterprise MITM proxies are pretty widely deployed. They may not currently implement h2 or h3, but that's not something we can rely upon.

Finally, just my .02 on naming - I think that 'connection tracing' is more evocative of what's going on, vs 'self tracing'. 'Self' implies a role (client, server, etc.), but that's not what's being traced.

Cheers,

> On 13 Aug 2021, at 4:14 pm, Kazuho Oku <[email-masked]> wrote:
> 
> Hello folks,
> 
> Today Jana and I have submitted a tiny I-D called draft-kazuho-httpbis-selftrace.
> 
> The draft specifies a well-known URI to be used for providing a trace of a particular HTTP/3 connection (e.g., qlog) on that same HTTP/3 connection.
> 
> One of the biggest hurdles in analyzing HTTP/3 performance issues is obtaining traces that show the symptoms. That is because clients being affected by issues have to coordinate with the server operators to collect the traces.
> 
> This PR solves the problem by defining a well-known URI for serving a trace to the client on the HTTP connection that the client is using. When a user sees an issue, they can collect the traces themselves and provide it to the server operator.
> 
> We have already implemented the feature in h2o, and doing so was easy, assuming that the underlying QUIC stack already defines callbacks for collecting trace events, see lib/handler/self_trace.c of https://github.com/h2o/h2o/pull/2765.
> 
> We also have a public endpoint; to try it out, first open https://ora1.kazuhooku.com/test/self-trace/video-only.html (which starts streaming a video), then open https://ora1.kazuhooku.com/.well-known/self-trace. While the video is being served, you would see the trace flowing through the well-known URI.
> 
> At the moment, we are using a custom JSON format for the trace, but when gzip compression is applied on-the-fly, the overhead of sending a trace alongside ordinary HTTP responses is less than 10%. Therefore, we tend to believe that this approach would work well in practice.
> 
> URL:            https://www.ietf.org/archive/id/draft-kazuho-httpbis-selftrace-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kazuho-httpbis-selftrace/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-selftrace
> 
> 
> Abstract:

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

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 14 Aug 2021 13:03:44 -0400

> I'm not sure that's a reasonable assumption; enterprise MITM proxies
> are pretty widely deployed. They may not currently implement h2 or
> h3, but that's not something we can rely upon.

In fact, there are enterprise MITM proxies that inspect H2 already -- we
have been helping to test them for a few years now. I do not know about
H3 because Web Polygraph does not support H3 yet.

Cheers,

Alex.

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 15 Aug 2021 01:03:36 +0100

Hello,

Spinning off a new thread to focus on privacy.

On Fri, Aug 13, 2021 at 5:28 PM Robin MARX <robin.marx=
[email-masked]> wrote:

>     As said in 4), I don't feel this necessarily should be limited to
> qlog, but a lot of the privacy issues+mitigations inherent to exposing logs
> will be discussed for qlog and should probably be referenced for this
> approach as well.
>     This could be used to ask end-users to capture a trace of a
> problematic connection and upload it for analysis. If the end-user isn't
> very technical, they might not know which info they're exposing. Even if
> they are, they probably don't want to go through the trouble of sanitizing
> the logs themselves.
>     Put differently: this should probably either be restricted to expose
> no privacy-sensitive info at all (or at least discuss the issues) or allow

I'm not so fussed on what text goes where. But I have a nagging concern
that we (collectively) aren't great at defining this type of thing, and we
should do better. The collect all and scrub model leaves me itchy.
Different applications that already have the ability to logs lots of detail
(e.g. Chrome netlog), seem to have different views on what "private data"
is. Where do they define that and is it consistent? Are there regulatory
considerations we should also be thinking about?

More specifically, and this is by no means a criticism of the editors,
qlog's security and privacy section is 3 paragraphs of TODOs [1]. I think
it would be great to find some people that could channel their knowledge or
expertise to start populating it with direct contributions, references, or
in contribution to some broader companion doc.

Cheers,
Lucas

[1] -
https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-00#section-9

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 14 Aug 2021 23:18:30 -0500

If I might top-post, I had thoughts about a couple of things people said at
various points in the thread ...

   - Kazuho, thank you for submitting this proposal.
   - I agree that this concept doesn't need to be tied to qlog, even if
   initial implementations use it with qlog.
   - I see that people have provided questions and concerns. It seems
   simpler to have those conversations if the well-known URI is described
   separately, and at a high level, and other specifications describe specific
   usages and how the concerns would be addressed in specific usages.
   - I would hope that it would be easier for operator types to engage in
   discussion about a general capability, and I can imagine that people
   looking at a description of the general capability might propose additional
   usages that we might not have thought of, because we're thinking about the
   qlog usage.

Best,

Spencer

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 15 Aug 2021 15:20:16 +0900

Hello Robin,

Thank you for your comments. My responses inline.

2021年8月14日(土) 1:28 Robin MARX <[email-masked]>:

>     I understand this is a tradeoff (you don't want to keep full traces
> for all connections just in case they are requested), but I feel we might
> want a way to indicate at the very start (e.g., transport parameter) that a

That's a good point.

While our PoC starts collecting the trace from the moment when the server
receives the request to the well-known URI, I do not think we are tied to
doing that. And I think that we probably do not need a TP.

A server can allocate a fixed-size buffer for each connection, retaining
the first N events that occurred for that connection. When it receives a
request for the well-known URI, it could send those events being recorded
and then send the events that follow. Recording few events during the
startup of a connection is probably alright, as the cost of logging would
be negligible compared to that of the TLS handshake.

> do this, but still a practical hurdle.

Right. I would hope that it would be possible to implement this as a
browser extension at least (with the assumption being that requests from a
browser extension would be coalesced with other requests going to the same
authority).

> [3], but good to bring it up on the list as well.

I would argue that there are differences between tracing a program and an
interchange format being used for analysing transport issues. What we emit
is the trace of h2o, that *can* be converted to qlog.

To give an example, we might have a call graph of functions like this:
quic::on_quic_ack // processing of a QUIC ACK frame
  -> quic::on_quic_ack_one_pn // processing of a particular packet number
being acked
    -> h3::on_buffer_shift // some bytes are removed from the send buffer
      -> proxy::on_upstream_unblock // the proxy is unblocked from reading
more data from upstream
        -> proxy::read_data // proxy reads data from upstream, queued in
the receive buffer
          -> h3::notify_data_ready // h3 layer is notified that there is
more data to be sent
            -> quic::notify_data_ready // QUIC stack is notified that there
is more data to be sent

and for the purpose of analysis, we want to emit traces that preserve these
kinds of call graphs, or to paraphrase, log events that happen in their
order, regardless of where they happened.

In this example, H3- and proxy-level events can happen for each PN being
ACKed. However, I do not recall if it was possible with qlog to emit an H3
event while processing an ACK frame.

I could well be wrong about how we could use qlog, but regardless, the
broader point is that we do not want our tracing capabilities to be
constrained by the limits of qlog. Emitting traces our own way preserves
the most information, with minimal effort. If necessary, we can
post-process the traces to qlog format to use the tools developed by the
community.

> I am very excited by the proposal and would love for some large
> deployments to offer this service.

-- 
Kazuho Oku

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 14 Aug 2021 22:13:01 -1000

On Sat, Aug 14, 2021 at 8:24 PM Kazuho Oku <[email-masked]> wrote:

>
>
>> 3) Relatedly, your POC seems to assume the browser will have just a
>> single connection and a trace request in a second tab will auto map to that
>> connection.
>>
>>      Not a big problem ofc, and things like Chrome's netlog export
>> already do this, but still a practical hurdle.
>>
>

Unfortunately, browsers do not guarantee this property, and past efforts in
the IETF to standardize features that assume this property (e.g. Token
Binding) or in other SDOs (e.g. ETSI’s unfortunate design with regards to
QWACs) end up not working in practice.

This is especially true as browsers look to segment connections even
further, in relation to privacy properties unique to browser environments
(e.g. CORS credentialless, as further expanded by COEP, or the fetch()
specifications Network Partition Keys, or security isolation primitives to
restrict extension access).

I don’t have much stake in this, other than flagging that any design that
makes assumptions about connection properties to bits on screen are,
generally, flawed assumptions. That’s not to preclude the possibility of
direct browser integrations, should it prove useful and of demonstrable
value to merit such implementation, although past efforts have failed to
achieve that value relative to the complexities of such coupling.

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 15 Aug 2021 18:01:30 +0900

> in contribution to some broader companion doc.

I agree that it would be reasonable to write down the risks of logging
information, especially the application data being sent in cleartext.

At the same time, I would point out that servers can log whatever they
want, regardless of what qlog or any specification says. So if we are to
provide some guidelines (or even just warnings), that is going to be an
improvement.

The same argument applies to requiring a client's action (to upload the
trace). It cannot be worse than servers retaining traces and using them
whatsoever.

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 15 Aug 2021 15:59:10 +0100

Agree with all your points Kazuho. This topic probably extends to toxic
telemetry more broadly, which is a mighty task. In the short term
establishing some common criteria had value for implementions and
deployments.

Cheers
Lucas

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Aug 2021 17:50:47 +0000

Oops, this was a reply to the wrong thread—meant for the tracing discussion (as likely one would infer).
-=R

From: QUIC <[email-masked]> on behalf of Roberto Peon <fenix=[email-masked]>
Date: Sunday, August 15, 2021 at 10:49 AM
To: Ryan Sleevi <[email-masked]>, Kazuho Oku <[email-masked]>
Cc: Jana Iyengar <[email-masked]>, Robin MARX <[email-masked]>, IETF QUIC WG <[email-masked]>, HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

My main concern would be side-channel attacks.
What kind of information can be gleaned by the size/timing of the trace as it is sent from one side to another?
What hypotheses does it allow an attacker to verify?
-=R

From: QUIC <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Sunday, August 15, 2021 at 1:13 AM
To: Kazuho Oku <[email-masked]>
Cc: Jana Iyengar <[email-masked]>, Robin MARX <[email-masked]>, IETF QUIC WG <[email-masked]>, HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

On Sat, Aug 14, 2021 at 8:24 PM Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

3) Relatedly, your POC seems to assume the browser will have just a single connection and a trace request in a second tab will auto map to that connection.
    That works fine for the POC, but for a real deployment that lets end-users fetch traces, you'd need built-in browser/client support to select a specific connection / fetch traces for all connections to a given origin.
     Not a big problem ofc, and things like Chrome's netlog export already do this, but still a practical hurdle.

Right. I would hope that it would be possible to implement this as a browser extension at least (with the assumption being that requests from a browser extension would be coalesced with other requests going to the same authority).

Unfortunately, browsers do not guarantee this property, and past efforts in the IETF to standardize features that assume this property (e.g. Token Binding) or in other SDOs (e.g. ETSI’s unfortunate design with regards to QWACs) end up not working in practice.

This is especially true as browsers look to segment connections even further, in relation to privacy properties unique to browser environments (e.g. CORS credentialless, as further expanded by COEP, or the fetch() specifications Network Partition Keys, or security isolation primitives to restrict extension access).

I don’t have much stake in this, other than flagging that any design that makes assumptions about connection properties to bits on screen are, generally, flawed assumptions. That’s not to preclude the possibility of direct browser integrations, should it prove useful and of demonstrable value to merit such implementation, although past efforts have failed to achieve that value relative to the complexities of such coupling.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Aug 2021 17:49:29 +0000

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Aug 2021 17:52:49 +0000

Let’s disregard my reply in the other thread, and discuss here instead..

Side-channel attacks should be on the docket for discussion too.
Trace-data seems ripe for abuse if we don’t carefully game out where it can be used to answer an attacker’s hypothesis…
-=R

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Sunday, August 15, 2021 at 8:00 AM
To: Kazuho Oku <[email-masked]>
Cc: Jana Iyengar <[email-masked]>, IETF QUIC WG <[email-masked]>, HTTP Working Group <[email-masked]>, Robin MARX <robin.marx=[email-masked]>
Subject: Re: Privacy considerations of trace logging (was Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt)

Agree with all your points Kazuho. This topic probably extends to toxic telemetry more broadly, which is a mighty task. In the short term establishing some common criteria had value for implementions and deployments.

Cheers
Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Aug 2021 09:56:03 +1000

On Sun, Aug 15, 2021, at 18:13, Ryan Sleevi wrote:
> Unfortunately, browsers do not guarantee this property, and past 
> efforts in the IETF to standardize features that assume this property 
> (e.g. Token Binding) or in other SDOs (e.g. ETSI’s unfortunate design 
> with regards to QWACs) end up not working in practice.

Rather than .well-known, would it help to negotiate a tracing endpoint for a request?

GET /test-video HTTP/?
Host: example.com
Trace: ?1

200 OK
Link: </trace/6sw3vfg5n7>;rel=trace

...

You might get the same trace URL for all requests, but you can bind connection-level information into the URL.

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 15 Aug 2021 21:33:05 -0400

> Rather than .well-known, would it help to negotiate a tracing endpoint for

I don’t see why it would help? Isn’t this assuming the subsequent request
will be negotiated over the same transport connection, which is not
something guaranteed by any modern browser?

The approach suggested would suffer similar issues as, say, SDCH. For
example, imagine two parallel requests started on a single transport
connection. The first request establishes an alt-svc mapping, which lead
the browser to prime connecting to that alt svc. The second request
establishes/negotiates the Link Rel you just mentioned. However, the fetch
of the link rel/well known then happens on that newly established
connection.

Meanwhile, the original connection may end up getting reused for subsequent
queued requests (e.g. due to biases towards InitCwnd), or might round robin
through the original and alt-svc as requests are being satisfied.

Nothing prohibits this today, and there are already a host of timing
interactions in implementations of fetch() due to origin-wide
policies/behaviours that get configured/associated with individual
requests, that it’s not… unlikely.

Now, it’s possible that you’re suggesting the browser take special action
on encountering such relationships, beyond simply making it observable
(e.g. to JS/extensions). If that was the intent, then I think we’re in
agreement - that is, that browser networking stacks would have to be
especially aware of this work, and have special behavior to handle it, for
this to be predictably useful in browsers. That’s not at all an argument
against this work, but rather, an expression that modern browser networking
is complex enough that you don’t get things free and easy, whether directly
or through extensions: it has to be designed in and intertwined with every
other feature.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Aug 2021 11:46:57 +1000

On Mon, Aug 16, 2021, at 11:33, Ryan Sleevi wrote:
> I don’t see why it would help? Isn’t this assuming the subsequent 
> request will be negotiated over the same transport connection, which is 
> not something guaranteed by any modern browser?

No, I wouldn't assume anything of the sort.  The contract would be that this URL, no matter how it was resolved, would return a trace for the connection(s) on which the original request was made.

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 16 Aug 2021 11:45:08 +0900

Mark, Alex,

Thank you for your comments. I think your concern regarding intermediaries
is legitimate.

One way of moving forward would be to say that intermediaries should not
forward the self-trace request. IIUC, we already have a precedent that
requires some intercepting proxies modify the request-response: when
expect-ct: enforce is being used, an intercepting proxy (typically using a
certificate not registered to CT) has to drop that response header,
otherwise the browser would refuse to reconnect.

Though, the problem here might be lack of incentive. While intercepting
proxies would be incentivized to drop expect-ct (if they see errors due to
the header being forwarded), there would be no incentive for them to add
code for rejecting self-trace requests.

That said, if we are to adopt MT's proposal (i.e., use a response header
for indicating the location of the trace), then probably we would have
better alignment because it would be about having a list of response
headers that an intercepting proxy might want to drop (i.e. except-ct and
the trace header).

The other option would be to add a H3 settings frame that indicates that
the endpoint is an end-client. Though I would prefer having a tracing
scheme that does not require changes to endpoints.

2021年8月15日(日) 2:03 Alex Rousskov <[email-masked]>:

> >> The draft specifies a well-known URI to be used for providing a trace
> of a particular HTTP/3 connection (e.g., qlog) on that same HTTP/3
> connection.
> >>
> >> At the moment, we are using a custom JSON format for the trace, but
> when gzip compression is applied on-the-fly, the overhead of sending a
> trace alongside ordinary HTTP responses is less than 10%. Therefore, we
> tend to believe that this approach would work well in practice.
> >>

-- 
Kazuho Oku

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 16 Aug 2021 17:03:17 +1200

On 16/08/21 2:45 pm, Kazuho Oku wrote:
> Mark, Alex,
> 
> Thank you for your comments. I think your concern regarding 
> intermediaries is legitimate.
> 
> expect-ct: enforce is being used, an intercepting proxy (typically using 
> a certificate not registered to CT) has to drop that response header, 
> proxies would be incentivized to drop expect-ct (if they see errors due 
> to the header being forwarded), there would be no incentive for them to 
> add code for rejecting self-trace requests.
> 
> headers that an intercepting proxy might want to drop (i.e. except-ct 
> and the trace header).
> 

IMO a mechanism that uses Client-Hints to modify the response type of 
TRACE method would meet requirements of this feature better than 
.well-known URIs.

The TRACE mechanism has existed in HTTP since 1.1 so all agents should 
be able to support it cleanly by now.

Agents not implementing the new mechanism will "fallback" to responding 
with details of what the responding server sees arriving: Via, Forwarded 
traces etc. Which may be of some use for troubleshooting even in absence 
of the self-trace information.

Client-Hints comes with most HTTP handling behaviours pre-defined, so 
should not need re-defining for this new mechanism.

Amos

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Aug 2021 12:53:59 +0900

2021年8月16日(月) 10:50 Martin Thomson <[email-masked]>:

> No, I wouldn't assume anything of the sort.  The contract would be that
> this URL, no matter how it was resolved, would return a trace for the
> connection(s) on which the original request was made.
>
>
Martin, thank you for suggesting this. I like it.

I think this might be the correct thing to do, being uncertain if browsers
would send requests for traces over the same connection.

For privacy reasons (and probably also for security reasons), the
requirement we have is that only the client that created the connection
should be capable of fetching the trace.

In the original approach, we had the implicit binding between the
connection to be traced and the trace request - the trace request was sent
over the connection to be traced.

In the proposed approach (of using a response header field that points to
the URL from which the trace can be obtained), an explicit token can be
included in that URL (or the server can send an authentication token if
necessary).

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 17 Aug 2021 14:05:35 +1000

> should be capable of fetching the trace.

For something like this, I would start by suggesting a capability URL: https://www.w3.org/TR/capability-urls/ (which is along the lines of what you contemplate; but in case you needed a name to hang this off).

Of course, capability URLs have a ...mixed reputation.  Nothing stopping you from adding tokens or passwords or crypto or something, but each additional protection comes with costs.  I'd want to see that the cost was justified before going for anything more complicated.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Aug 2021 13:53:19 +0900

Hi, Amos,

Thank you for your comment.

> TRACE method would meet requirements of this feature better than

While we can use  theTRACE method, I'm not sure if that simplifies things.

The key difference from the TRACE method and self-trace is that the former
works at resource level, while the latter works at the connection level.

TRACE has to be a special method because it changes how the resource
specified by the URI responds. In contrast, trace of the underlying
connection is not a property of an URI.

Based on that, I tend to believe that we can use the URI to designate a
service providing the self trace. If we look that way, use of a well-known
URI is a good fit, and it does not have issues like what happens with
fallbacks.

-- 
Kazuho Oku