--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFrqBGXeQxseM3U1pFi-bZWY3d1XWcAOsykuKCMtxg7WVQ%40mail.gmail.com.
I would suggest that the problem may be more complex than you've suggested in the design doc. I don't know if I'm a good person to be the reviewer, however, because I'm not sure what the 'right answer' is. Perhaps rdsmith@, gavinp@, or mmenke@ would know?
Consider the case of 'encodedBodySize'. My understanding (perhaps incorrect) of our current cache implementation is that the entry we write to the cache is after filters have been done. This is particularly important for the SDCH case, since the SDCH dictionary is an independent resource and things would get all sorts of 'hinky' if we were decompressing on the fly (again, this could be an incorrect understanding, and perhaps we're already in the Hinky Hinterlands and trying to fix it). As a result, we don't store the encodedBodySize in the disk cache - because we're always storing the entry decoded after content translations.
I'm a little nervous about your proposal for handling transferSize. Innately, it feels like it's the wrong layer - but I'm not sure what the concrete suggestion should be. //net is generally unaware of the CORS aspects of Fetch, intentionally, while it seems like transferSize needs to handle that. Changing the timing of Drain() so that you can count the body bytes against the request also seems... less than ideal... even though it's clear why you desire that to be the case (since, at least at present, we still drain the socket in the event we might be able to use it for a keep-alive). There's something in my gut that tells me it's going to have any number of edge cases with non-success response codes, but I can't put my finger on the concrete concern. It may introduce flake where there was none - in the past, we could continue with the next request, and the Drain() cost would be counted against returning the socket to the pool (IIRC), whereas now, if the Drain() fails, it'd manifest as a request job failure (because it'd be handled as a failure before being handled as a redirect). It's also not clear how 'synthetic' redirects (e.g. HSTS) will behave - we inject some data in via a synthetic job, but it's not actually transferred over the wire.--On Mon, Jun 6, 2016 at 9:05 PM, 'Adam Rice' via net-dev <net...@chromium.org> wrote:Hello net folks,--I am working to add three new size fields to the PerformanceResourceTiming API (see issue 467945 and the spec at https://www.w3.org/TR/resource-timing/).There are two size fields that are not currently exported by net. Specifically the "transferSize" field, which is the total byte size of the HTTP response including same-origin redirects, and the "encodedBodySize" field, which is the size of body prior to removing content compression. Some (relatively small) changes will be needed in net to export these values.I am currently at the stage of finishing up the design and starting the implementation.I am hoping someone from net will take a look at the design doc: https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8KduY/editIf the same person later did the code reviews, that would save time.Thanks,Adam
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFrqBGXeQxseM3U1pFi-bZWY3d1XWcAOsykuKCMtxg7WVQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvbHZdhtWVzOVs4U68Q3aKFKU4w7GJ-t7%3DmEDr97mwW4xA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFbEG_rR23K09-qoBQFrKHK%3DmT%3D45KAvWESYyA9Cz15US9ZM2A%40mail.gmail.com.
Adding bengr+tbansal in case they have some ideas, since they have done some work on data accounting.On Tue, Jun 7, 2016 at 12:57 PM Randy Smith <rds...@chromium.org> wrote:On Tue, Jun 7, 2016 at 12:48 PM, Ryan Sleevi <rsl...@chromium.org> wrote:I would suggest that the problem may be more complex than you've suggested in the design doc. I don't know if I'm a good person to be the reviewer, however, because I'm not sure what the 'right answer' is. Perhaps rdsmith@, gavinp@, or mmenke@ would know?Consider the case of 'encodedBodySize'. My understanding (perhaps incorrect) of our current cache implementation is that the entry we write to the cache is after filters have been done.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAAuiYA8%3DP%2B4DLP3oAKppVN4dioyU9mQHhew7ZqefM%2BMLenj7dQ%40mail.gmail.com.
I'm a little nervous about your proposal for handling transferSize. Innately, it feels like it's the wrong layer - but I'm not sure what the concrete suggestion should be. //net is generally unaware of the CORS aspects of Fetch, intentionally, while it seems like transferSize needs to handle that. Changing the timing of Drain() so that you can count the body bytes against the request also seems... less than ideal... even though it's clear why you desire that to be the case (since, at least at present, we still drain the socket in the event we might be able to use it for a keep-alive). There's something in my gut that tells me it's going to have any number of edge cases with non-success response codes, but I can't put my finger on the concrete concern. It may introduce flake where there was none - in the past, we could continue with the next request, and the Drain() cost would be counted against returning the socket to the pool (IIRC), whereas now, if the Drain() fails, it'd manifest as a request job failure (because it'd be handled as a failure before being handled as a redirect). It's also not clear how 'synthetic' redirects (e.g. HSTS) will behave - we inject some data in via a synthetic job, but it's not actually transferred over the wire.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAF8qwaBwNc4AiT_AbdaMMNS0_j-s5f68iTJH7fPzS9nN_aRCpA%40mail.gmail.com.
Ahh, I guess we only give response header size, not request header size, so scratch the auth password concern, though with HTTP requests over a proxy, they still get auth challenge lengths, which still seems really weird.On Tue, Jun 7, 2016 at 10:52 PM, Matt Menke <mme...@chromium.org> wrote:Transfer-Encoding is treated as Content-Encoding, and I believe we even allow things like "Transfer-Encoding: gzip", "Content-Encoding: gzip" on a file, and expect it to only be gzipped once. Isn't the web great?
What does body size mean, in the context of QUIC/SPDY? Does it include the framing around the body or not? What about chunked-encoding? If we're using a SPDY proxy, does it include the SPDY frames, then? Does it even make sense to send this information in the case of a proxy? We've long since given up on exposing a proxy is in use, of course, but we're given the webpage information that doesn't seem particularly relevant to them. And if there are auth headers, we're potentially exposing the length of auth passwords, aren't we?
This attribute should include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but should not include lower-layer protocol overhead (such as TLS [RFC5246]or TCP).
That sounds like a spec issue? Happy to clarify here, but also possible on the Resource Timing/WebPerf WG.
Chris, which part are you referring to? Specifically calling out in the spec that QUIC overhead should be accounted for?I think Adam's question was more specifically oriented towards our internal API which omits the framing overhead for QUIC.. (but should, I think :))
Wait, I'm confused.. The definition we provide in the spec excludes "lower layer" overhead - e.g. TLS, TCP, etc."This attribute should include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but should not include lower-layer protocol overhead (such as TLS [RFC5246]or TCP)."FWIW, I think it's reasonable to read QUIC overhead as ~HTTP overhead.
Wait, I'm confused.. The definition we provide in the spec excludes "lower layer" overhead - e.g. TLS, TCP, etc."This attribute should include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but should not include lower-layer protocol overhead (such as TLS [RFC5246]or TCP)."FWIW, I think it's reasonable to read QUIC overhead as ~HTTP overhead.
Wanted to jump in here w some thoughts about what kinds of use cases FB would have here and I think other developers might have.
IMHO we will mostly rely on this info for estimates of resource size. We understand that framing introduces overhead at multiple levels. we'd prefer an api that gives the most accurate possible estimate of size. Of that estimate changes over time or across browsers that's ok so long as we only get more accurate. If a browser could reasonably account for overhead from quic or ssl we'd love to have the spec change to allow for that to be accounted for.
I'm puzzled what use this bandwidth measurement is. (For instance, I could pathologically chunk my stream into records at the TLS layer to cause the real bandwidth used to be nearly 40x the reported number or so. Though no one would do that since it's crazy.)
In both cases, we're right. In both cases, we're wrong. The 'bug' is the spec language assuming there is a clear split, when in cases like QUIC, there isn't. Whether that's a fault of QUIC (for blurring the lines) or the spec (for assuming defined lines), I'm not sure, but I don't feel the spec unambiguously supports your conclusion, so there's something to be improved here.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvbsevvGFh-Bg1o%2B22m5zXeW8XNREcgT3%3DSeCQWooRQr3A%40mail.gmail.com.
On Tue, Jun 14, 2016 at 6:17 PM, David Benjamin <davi...@chromium.org> wrote:I'm puzzled what use this bandwidth measurement is. (For instance, I could pathologically chunk my stream into records at the TLS layer to cause the real bandwidth used to be nearly 40x the reported number or so. Though no one would do that since it's crazy.)Identifying such pathological cases is precisely one of the use cases -- e.g. due to a misbehaving upstream proxy/CDN node/whatever.
(4) Accounting for other types of overhead in trasnferSize (http framing, quic, ssl [if we changed the spec to allow that], redirects, etc).
On Wed, Jun 15, 2016 at 3:38 AM, Ben Maurer <ben.m...@gmail.com> wrote:(4) Accounting for other types of overhead in trasnferSize (http framing, quic, ssl [if we changed the spec to allow that], redirects, etc).Thanks for replying, Ben. I totally agree with you that the perfect is the enemy of the good. If the spec made no mention of overheads or trying to include them, I think that'd be great!I think for all of the use case you mentioned on this last point, this is all something that can be recorded at the server - save for redirect overhead (which I agree, is less about bandwidth and more about latency). For example, the TLS overhead in sending resources is dictated by the server. The HTTP/2 overhead and header compression is dictated by the server (although I suppose also the number of requests the client has in flight, but any given request must be compressed by the server). The same applies to QUIC. So it's unclear what adding it to the browser side would be as the intrinsic value-add - the uncharitable, but may be entirely accurate, view would be that it makes browser developers do the work that server developers could/should do.
Ilya, given the fundamental issues with accounting for "overhead" or quantifying things other than the request, would you be supportive of removing any such mentions from the spec, and a focus on the Chromium implementation of ignoring those general overheads in favor of specific, quantifiable measurements?
My suggestion would be to make the spec use language like this:Implementations should strive to capture as much overhead as possible. Some types of overheads (eg, complex protocols like QUIC or framing overheads of TCP and SSL) may be difficult or impossible to measure. Implementations must only attribute bytes that can be exclusively attributed to a request.
Does that sound reasonable?
On Mon, Jun 27, 2016 at 9:15 AM, Ilya Grigorik <igri...@google.com> wrote:Does that sound reasonable?Has there been identified an actual use case for that level of granularity? As far as I can tell, there hasn't been.
It seems like there was agreement that leaving this off in the spec is fine, and revisiting it when there's a clearer use case and more defined need would be an acceptable solution.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADXXVKqUnV1AygoyPgRyUaTbo6LXzhbknEiidrGDas%3DToHFC8A%40mail.gmail.com.