qlog update before IETF 120
Hello fellow structured logging enthusiasts, It is me again with an update on the qlog drafts, which had new versions published last week [1]. The focus this time was on finalizing (well-defined) extensibility in two main ways: 1. making all events and structures properly extensible through CDDL constructs [2] (meaning later extensions can use tools for automatic code checking, schema validation, example generation, etc. by hooking into extension points) 2. creating a framework to track which events/event documents are included in a given qlog file [3] (we have an explicit list of "event_schemas" defined by IANA-backed URIs, as well as a new "file_schema" concept) This means the extensibility work is now 95% done (of course we found an edge case right after submitting the drafts [4]) and that others can start utilizing/exercising these setups for new extensions. This has already been done in at least two concrete occasions: A. the "Convergence of Congestion Control from Retained State" draft at TSVWG has some qlog events defined [5] B. the "RoQ qlog event definitions" draft proposes qlog events for RTP over QUIC [6] *At this point, we feel the basic mechanisms are robust and stable enough for others to utilize them to define new qlog schemas. * I personally feel these were the last of planned main/breaking changes, so I'm also planning to start updating the qvis toolsuite [7] to support the newest qlog versions in August/September. I concretely plan to keep the current qvis version available as a "legacy" option (as-is, unmaintained), with the newer versions ONLY supporting the latest qlog drafts (so no backwards compat). In conclusion, I think we're still on track to move qlog to WGLC by the end of this year as planned. Most of the open issues/PRs are either very old (and can be closed with no/little action) or are simple/editorial-only changes. Only a few discussion points remain (mainly: adding a new timestamp/clock option [8]), which can probably be resolved by the editors/on the mailing list. *As such, early reviews of the documents are now welcomed.* *Additionally, you can now slowly start thinking of updating your qlog implementations to move to the new drafts. * At least one stack (xquic [9]) is already doing this, and this will be a big help in making sure the new qvis version remains a useful tool for debugging. Finally, I will personally sadly not be in Vancouver, but potentially Lucas Pardue will give a (small) update on qlog during the QUIC WG meeting (TBD). If people have any questions/remarks, do feel free to reach out via email to me or the other editors! With best regards, Robin (on behalf of the qlog editors) [1] https://github.com/quicwg/qlog [2] https://github.com/quicwg/qlog/pull/417 [3] https://github.com/quicwg/qlog/pull/424 [4] https://github.com/quicwg/qlog/issues/432 [5] https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-careful-resume-10#name-qlog-support-for-quic [6] https://www.ietf.org/archive/id/draft-engelbart-qlog-roq-events-00.html [7] https://qvis.quictools.info/ [8] https://github.com/quicwg/qlog/pull/290 [9]: https://github.com/alibaba/xquic/blob/main/docs/Features.md
Re: Why isn't QUIC growing?
Hey there Chris, Thanks for mentioning my blogs; happy that they're helpful. My 2 cents on this topic: 1. Just because a CDN supports HTTP/3 does not mean it enables it (by default) for all customers. For example, while Akamai (my current employer) provides support, it is explicitly opt-in instead of opt-out for existing customers, meaning we're probably at a much lower level of adoption than what's conceptually possible. I can't speak for other CDNs/large providers, but I imagine similar things happen there (e.g., only enable it by default for free/small customers, but require manual action from larger entities, which can be slow in the uptake). 2. Even if it's enabled, the alt-svc-based bootstrapping/discovery means you'll still have plenty of HTTP/2 by design. And while Chrome and Firefox pretty aggressively switch from H2 to H3 when discovered (even during a page load), Safari/Apple (at least for a long time, not 100% sure what they do not) kept using H2 for as long as possible, only switching to H3 when a new connection was really needed. This will (probably) be improved by HTTPS DNS records and alt-svc-bis, but those also have (current) deployment issues IIUC. 3. Even if the client tries HTTP/3, it will sometimes fail due to UDP rate limiting/blackholing/firewalling/flukes or things like MTU nasties that make HTTP/2 win the happy eyeballs race. I doubt this would contribute more than single-digit percentages to the overall number, but still a factor (I haven't seen recent numbers on this. Maybe Matt or Ian can comment, since they track more detailed client-side info?) 4. Outside of the browsers, there aren't many clients that actively support HTTP/3 (at least not by default, or in stable versions, see e.g., curl). Assuming again that say a single digit percentage of traffic (or should I say connections) is from non-browser clients, if that's counted in the stats, it'll also skew H3 potential. All that said, I must admit that I too have been surprised by Cloudflare Radar's numbers and their relative stableness over time :) Maybe Lucas can share some wisdom ;) With best regards, Robin On Mon, Jun 24, 2024 at 4:46 PM Chris Box wrote: > On Mon, 24 Jun 2024 at 13:51, Aaron Ding wrote: > >> we had a recent IEEE ICDCS work related to this subject: >> https://sk-alg.tbm.tudelft.nl/aaron/files/pre-icdcs2024.pdf >> >> > Thanks Aaron! > > Figure 2 is most illuminating. It shows that Google mostly serves HTTP/3, > but Cloudflare less than half H3, with all other major CDNs being mostly > H2. You also refer to https://w3techs.com/technologies/details/ce-http3 > which shows a slow upward trend from 26% to 30% in a year. > > So perhaps I should conclude that HTTP/3 adoption will significantly step > up when non-Google CDNs decide to deploy it more widely? > > In this space, Robin's APNIC posts are also useful: > https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-world/ and > https://blog.apnic.net/2023/10/23/the-challenges-ahead-for-http-3/. > > Chris > > -- Marx Robin +32 (0)497 72 86 94
Re: Comments on QLOG drafts
Hello Hugo, Thank you for this very thorough review of the QLOG documents! Some of your remarks were clear (editorial) errors and I have changed them in a single commit here: https://github.com/quicwg/qlog/commit/21a3de1ec3dbcef1c636d91d841fa597f683c8f9 Others also indicate valid problems, but will require additional discussion and/or work before being addressed in a PR. I have opened individual issues for them in the github repo at: https://github.com/quicwg/qlog/issues. Hopefully you're willing to continue the discussion there. Finally, for a few remarks, I'll offer my comments here, since I personally don't think they should be addressed (but might warrant further discussion in the wg through this mailing list): 1. For connectivity:spin_bit_updated's category: while I agree this is somewhat QUIC specific, the same could be set for the connection_id_changed event. This feels more like bikeshedding, so unless others have strong opinions, I'd keep it at connectivity. 2. For quic:datagrams_sent and logging other ToS fields: I think ECN is special here since it has a clear (potential) impact on transport-level congestion control. I don't agree that other IP-level fields should be logged here, and rather should get an IP-specific qlog event somewhere down the line. Similarly, IIUC QUIC implementations should ALWAYS request the "don't fragment treatment" from an OS? If not, then I also agree this should not be part of the datagrams_* events but rather part of a more general "configuration" field (which we removed a while back due to no concrete use cases ;)) 3. For recovery:congestion_state_updated and uppercase-ness of the ECN trigger value: ecn is consistently lowercase as field _name_ (as are all field names in qlog), but we have other instances where ECN-related _values_ are uppercase (and this is also a _value_, so I'd keep it at ECN) 4. For recovery:loss_timer_updated and clarifying the "timer_type": we currently have a comment pointing to RFC 9002 there; I would assume this is enough? 5. For AckFrame and not being able to log the receipt of ECN data without also logging the ECN values: I personally don't think this is sensitive enough data to need a way to log this without revealing the values. Additionally, one can arguably infer this through recovery:ecn_state_updated that they "should be there" (if not scrubbed by the network). 6. Several error codes should be uint64 instead of uint32: I think this was mainly because uint64 is a bit of a nuisance because it can be either an actual uint64 or text string due to wanting to support "I-JSON" in webbrowsers. Agreed that according to the spec, these should be uint64 and have changed this in the commit linked above. Thank you again for your time on this. It's very good to get input from a "new implementer" on the docs now that they've progressed so much from the initial points where most people implemented the format. With best regards, Robin On Thu, Jan 18, 2024 at 7:49 PM Hugo Landau wrote: > Hi, > > I've completed a review of the QLOG drafts and have some comments. Hope > these > are helpful. > > Comments on draft-ietf-quic-qlog-main-schema.md > === > > ## Custom fields\ > > Trailing backslash in this section title > > Comments on draft-ietf-quic-qlog-quic-events.md > === > > connectivity:connection_closed: > > This is missing the frame type field in the QUIC CONNECTION_CLOSE > frame which is rather useful information. > > connection_code can be a string or a uint32, but QUIC uses a variable > length integer here and thus this can be up to 62 bits. Same for the > application_code. > > It is up to the decoder to infer by presence of connection_code or > application_code to infer whether this was an application or transport > CONNECTION_CLOSE. But this requires it to log such a value. It would > be nice if this can be communicated without necessarily knowing the > actual value. Consider either adding a field to distinguish between > transport and app errors or replacing the "error" field of "trigger" > with "app_error" and "transport_error". > > connectivity:connection_id_updated: > > It would be nice to be able to optionally log CID-associated sequence > numbers and the type of CID source (ODCID, Initial CID, > preferred_address transport parameter, NCID frame, etc.) > > connectivity:spin_bit_updated: > > This is very QUIC-specific, so I question the value of it being defined > as a generic connectivity event. > > connectivity:mtu_updated: > > I suppose it is a bit of an asinine remark, but IPv6 jumbograms mean > theoretically you could do things with datagrams greater than 64k. > uint32? > > quic:version_information: > > Maybe clarify that if the client receives a version negotiation packet > with no viable overlap, it logs a version_information event with no > chosen_version? > > quic:alpn_informa
Re: qlog, AckFrame, and ack_delay
Hello Damien,
Thank you for bringing this to our attention.
I agree you have a point and have to admit that, at first, I was confused,
because I thought we already defaulted to logging the wire image/unscaled
value instead of the scaled one.
As such, I think your suggestion is a sensible one and I've created a PR
for it here: https://github.com/quicwg/qlog/pull/337
Feel free to comment more on that issue as well.
In absence of protest by others, this will be in the next draft versions.
With best regards,
Robin
On Thu, Nov 9, 2023 at 10:44 PM Damien Neil wrote:
> The qlog AckFrame type includes the ack delay as a float32 number of
> milliseconds:
>
> AckFrame = {
> frame_type: "ack"
>
> ; in ms
> ? ack_delay: float32
> ; ...
> }
>
>
> https://www.ietf.org/archive/id/draft-ietf-quic-qlog-quic-events-06.html#section-8.12.3
>
> Given a serialized ack frame, determining the delay as a duration requires
> knowing the ack_delay_exponent. In some cases, the logging endpoint may not
> have this available (if receiving an ack before transport parameters have
> been received). Even when available, it may not be easily accessible at the
> point of logging. For example, in my own implementation, I'd like to be
> able to convert a packet payload to a series of qlog event frames without
> needing to reference persistent connection state.
>
> I think there should be an alternative to log the raw value of the ACK
> Delay field:
>
> AckFrame = {
> frame_type: "ack"
>
> ; in ms
> ? ack_delay: float32
>
> ; integer value of the ACK Delay field, not scaled by the
> ack_delay_exponent
> ? unscaled_ack_delay: uint64
>
> ; ...
> }
>
> - Damien
>
--
Marx Robin
+32 (0)497 72 86 94
Re: qlog, AckFrame, and ack_delay
Hello all,
Sorry for the late reply from my end; I had some troubles posting to the
list and my original reply got lost in moderation.
I can appreciate both sides of the argument here.
Originally I tended more towards Damien's suggestion and opened a PR for it
at https://github.com/quicwg/qlog/pull/337.
However, I think Marten and Lucas make good arguments for things like
HTTP/3 header compression and packet number encoding needing "global"
persistent state to decode.
I also feel the unscaled ack value isn't really useful in tooling (which is
the main use case for qlog).
I also follow Lucas' argument that a good fallback option would be to log
the raw bytes using the "? raw: RawInfo" field.
However, for this I see that we don't have this explicitly defined for all
possible frames (including AckFrame) only on some (like StreamFrame or
UnknownFrame).
As such, if this option is chosen, we should add the explicit "raw" field
to all (most?) frames as well imo.
I'm guessing that would also meet Marten's approval?
With best regards,
Robin
On Fri, Nov 10, 2023 at 6:50 PM Damien Neil wrote:
> I believe the ACK Delay field is unique in the QUIC wire protocol in being
> a field which can't be interpreted without information from a separate
> protocol layer. I don't think this change leads to anything else.
>
> More precisely: Viewed as an integer, ACK Delay can be interpreted by
> considering the ACK frame alone. Viewed as a duration, it requires
> additional information exchanged in the TLS handshake. ACK Delay is the
> only field I know of which has this duality.
>
> I can write a function which takes a QUIC packet payload and outputs a
> list of qlog $QuicFrames, with the sole exception of the ACK Delay field
> which requires access to the ack_delay_exponent. And as the
> ack_delay_exponent is not known early in the handshake, it's currently
> impossible to fully log early ACK frames. (Probably the right choice under
> the current design is to not emit the ack_delay field in this case.)
>
> On Fri, Nov 10, 2023 at 9:20 AM Lucas Pardue
> wrote:
>
>> These use cases seem like they are more general than just one field in
>> one frame type.
>>
>> I don't want to commit to doing 1 thing if it's the start of a string of
>> work that updates many other events.
>>
>> Would you be willing to survey all current events (modulo qpack, which we
>> are removing) in order understand the full scope of change?
>>
>> Cheers
>> Lucas
>>
>> On Fri, 10 Nov 2023, 17:31 Damien Neil, > 40google@dmarc.ietf.org> wrote:
>>
>>> Consider an endpoint processing an ACK frame in an Initial packet
>>> received before transport parameters have been received. This can happen
>>> when, for example, a client's Initial CRYPTO flight is too large to fit in
>>> a single datagram; the server will send an ACK for the first Initial packet
>>> before it has the ability to send transport parameters in the Handshake
>>> flight. Or even in the case where the client Initial CRYPTO flight fits in
>>> one datagram, the server may respond with an ACK in an Initial packet prior
>>> to sending a Handshake packet.
>>>
>>> In this case, the client is processing an ACK frame that may contain a
>>> non-zero ACK Delay value, but has no ability to interpret it because it
>>> doesn't know the peer's ack_delay_exponent. I forget whether it's permitted
>>> for an endpoint to send a non-zero ACK Delay in an Initial packet, but even
>>> if it isn't, the recipient may want to log the value.
>>>
>>> Or one could imagine a tool which converts a pcap packet capture to a
>>> qlog file; in this case, the tool may have access to a key log to permit it
>>> to decrypt packets, but may be processing a section of the log that does
>>> not include the handshake.
>>>
>>> On Fri, Nov 10, 2023 at 12:48 AM Marten Seemann
>>> wrote:
>>>
There's a tradeoff here: Giving writers of qlog files more flexibility
comes at a cost to consumers of qlog files, who now need to support
multiple representations. There's a lot of value in having only a single
way to log something.
I'm not sure the proposal for unscaled_ack_delay strikes the right
balance here. For a consumer of a qlog file, I can't think of a single
scenario where the unscaled_ack_delay would provide any advantage over the
actual value, so introducing this option would purely to make the writer's
life easier. And I'm struggling to see why logging the ack_delay would
place a big burden on the writer, since a QUIC stack will need to decode
this field at some point anyway.
On Thu, 9 Nov 2023 at 22:44, Damien Neil >>> 40google@dmarc.ietf.org> wrote:
> The qlog AckFrame type includes the ack delay as a float32 number of
> milliseconds:
>
> AckFrame = {
> frame_type: "ack"
>
> ; in ms
> ? ack_delay: float32
> ; ...
> }
>
>
> https://www.ietf.org/archive/id/draft-ietf-quic-qlog-quic-events-
qlog London update
Hello all, right before the year's end, *rejoice*, for it's another qlog update on which we'd like some feedback for two points: Firstly, as you may recall, in London we presented plans to handle (future) qlog extensions mostly in separate drafts/RFCs. This got some chocolate-induced pushback, and we now have a new plan: 1. Include in the currently adopted documents all *direct* QUIC and HTTP/3 features and frames that are defined in an RFC / exist in IANA *by the end of 2022* - This includes: RFC9000 - 9003, 9114 (H3), 9204 (QPACK), 9221 (QUIC Datagram), 9287 (grease bit), 9218 (extensible priorities) and 9297 (H3 Datagram only) - Note: for 9297, we would *NOT include the capsule protocol,* as it's not a direct extension to QUIC/H3 and would introduce (excessive) additional complexity. - Note: this requires extending the current qlog scope (QUIC, H3 and QPACK only) to encompass the newer definitions 2. Anything published from 2023 onward can either include qlog definitions as part of its own document, or we will do periodic "bulk" update documents (e.g., qlog v2024) if required Secondly, we have included a first version of a "securities and privacy considerations" section in the documents [1]. As this is a key part of the text, we would greatly appreciate additional reviews and feedback on this section via the github issue [2]. We also plan to request an early secdir review in February 2023 to try and prevent major issues going forward. To allow us to make progress, we would like feedback on these points *by February 1st at the latest.* Otherwise, we will continue with the current plans. I wish you all a happy end of the year and let's make 2023 the year we see some qlog RFCs, shall we? :) With best regards, Robin [1]: https://www.ietf.org/archive/id/draft-ietf-quic-qlog-main-schema-04.html#name-security-and-privacy-consid [2]: https://github.com/quicwg/qlog/issues/259 -- 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
qlog update
Hello all, You've probably seen the new draft notifications for the 3 qlog documents last week [1][2][3]. We've had some good progress nudging towards WGLC this time, most of it editorial (see changelogs in each doc), but some key points as well that I'll present next week and already wanted to highlight here. First, we finally have some initial text for a "Security and Privacy Considerations" section [4]. As this is a key part of the docs, we would appreciate some additional eyes on this at issue 259 [5]. Secondly, to exercise the extensibility of the schema, we've created a new qlog definition for the QUIC and H3 DATAGRAM frames [6]. This is not intended to be a "real" document for adoption in the WG (at this time), but mostly a way to show you how extensions would work in the future + to find extensibility problems. This worked quite well as we found some gaps, and issue 261 [7] tracks this. Thirdly, there is some long-standing discussion whether we should add (basic) multipath support to the main qlog docs. Full multipath support is (imo) out of scope, but some low-level primitives could conceptually be provided, as they can also be used for connection migration. What that should look like is unclear however, see issue 134 [8]. Finally, we're thinking about splitting up the HTTP/3 and QPACK events in their own documents (currently they're together in [3]). This would be more consistent with the qlog QUIC document, with the H3 and QPACK RFCs, and with envisioned qlog extensions, as discussed in issue 262 [9]. These and even more exciting topics in next week's qlog slot @ IETF 115! With best regards, Robin [1]: https://www.ietf.org/archive/id/draft-ietf-quic-qlog-main-schema-04.html [2]: https://www.ietf.org/archive/id/draft-ietf-quic-qlog-quic-events-03.html [3]: https://www.ietf.org/archive/id/draft-ietf-quic-qlog-h3-events-03.html [4]: https://www.ietf.org/archive/id/draft-ietf-quic-qlog-main-schema-04.html#name-security-and-privacy-consid [5]: https://github.com/quicwg/qlog/issues/259 [6]: https://github.com/rmarx/draft-marx-quic-qlog-datagram [7]: https://github.com/quicwg/qlog/issues/261 [8]: https://github.com/quicwg/qlog/issues/134 [9]: https://github.com/quicwg/qlog/issues/262 -- 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
Re: I-D Action: draft-ietf-quic-v2-01.txt
Hello Martin, As someone who had seen a lot of misinformation spread about HTTP/2 and actively tried to prevent the same happening for HTTP/3 and QUIC by providing "correct" sources early on, I can sadly only agree with Lucas here. There will always be people who don't do any of the legwork required to actually understand what's happening and who take things at face value. This is why even today we have articles claiming HTTP/3 doesn't retransmit lost data because it uses UDP under the hood... Switching to another naming scheme just to appease this group would probably not have the intended effect + make it more obtuse for the rest in the long run. So I'd personally also advocate just calling it 2QUIC2Soon. With best regards, Robin On Sat, 22 Jan 2022 at 16:06, Lucas Pardue wrote: > Hi Martins, > > Wearing no hats. > > > On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, > wrote: > >> Hello everybody, >> >> The following concern just popped up in my mind: >> >> Some people (in particular the press,...) may take version numbers very >> seriously. Reading "QUIC version 2", my guess is that there might be >> articles saying things such as "Quic already is at version 2" or "Quic >> version 1 is outdated, use version 2", and so on. >> >> Everybody on this list (including me) of course understands that such >> stuff is completely wrong, and it's easy for people who want to figure >> out that it's wrong. Nevertheless, there are quite a few instances where >> version numbers have taken a life of their own. >> >> The purpose of this mail is that everybody consider the risk of the >> above "misunderstandings". If we are fine with that risk, then let's go >> with "version 2". If we have some doubts, it would be easy to change the >> version number to something else, such as 1.1, or 0.99, or A.bc, or >> whatever. >> > > Whatever moniker we chose, I think there will be some part of the > population that will be surprised and read something more into it than what > the specification is attempting to do or solve. Personally I think QUIC 1.1 > would be a very bad name though. > > I've lost count of the times I've seen a comment like "I've only just > heard about HTTP/2, and now there is an HTTP/3?". > > This spec will help exercise our version negotiation mechanism and help > prevent stagnation and ossification. In some sense we are trying to build > an evergreen transport, to borrow a w3c term [1]. Perhaps people should > become accustomed to a new version of QUIC being released on a regular > cycle, so that implementer and operators build out the processes needed to > stay compatible and up-to-date. > > Cheers > Lucas > > > [1] - https://www.w3.org/2001/tag/doc/evergreen-web/ > > > >> -- 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
Re: EPIQ Workshop 2021
Hello everyone, This is a small reminder that the QUIC-focused academic workshop called EPIQ will take place next week Tuesday, December 7, between 12h and 18h CET. We have a very interesting programme with keynotes from Microsoft and Apple about their QUIC usage, as well as 6 academic papers covering topics such as Path MTU determination, MASQUE proxying, Real-Time media congestion control, HTTP/3 adaptive streaming, spin bit tracking and formal implementation verification. We might also have a panel to discuss QUIC's future. You can find more information on the workshop's webpage here: https://epiq21.github.io Do note that you have to register for the CoNEXT conference in order to be able to attend. This can be done via https://conferences2.sigcomm.org/co-next/2021/#!/registration, and should be opening up soon (today or tomorrow). We hope to see you all there for some interesting QUIC discussions! Robin, Chris, Lars and Jörg On Tue, 14 Sept 2021 at 21:58, Robin MARX wrote: > Hello everyone, > > Just a small update on the upcoming EPIQ workshop, which will be > co-located with the CoNEXT conference in December. > > The paper and poster submission deadline has been extended from September > 17 (this Friday) to September 24 (next week Friday, Anywhere-on-Earth), > to give you all a bit more time to submit interesting work. > > All other information can still be found on the web page: > https://epiq21.github.io > > Looking forward to reading lots of interesting stuff, > Robin, Chris, Lars and Jörg > > On Tue, 20 Jul 2021 at 14:35, Robin MARX wrote: > >> Hello everyone, >> >> I am happy to announce that the EPIQ workshop's 3rd installment has now >> been confirmed for CoNEXT 2021! >> >> The main goal of the workshop is to provide a venue for discussion on all >> things QUIC and related technologies (e.g., HTTP/3), between both academia >> and industry. >> Next to typical research reports, we encourage the submission of early >> work and results, brave new ideas and reproduced results from earlier work. >> >> Besides paper and poster discussions, we also plan to have a keynote >> speaker and potentially a panel discussion. >> I will be reaching out to some people about this in the coming weeks, but >> if you feel you can provide an interesting keynote or you would be an >> engaging panelist, please let us know! >> >> >> Submission deadline is Friday *September 17*, with the workshop taking >> place entirely online on Monday *December 6*. >> Please find more information at https://epiq21.github.io >> >> >> Hoping to receive an abundance of interesting work, >> Robin, Lars, Jörg and Chris >> >> >> On Thu, 10 Jun 2021 at 16:59, Robin MARX wrote: >> >>> Hello all, >>> >>> I wanted to send a small update regarding the academic EPIQ workshop. >>> >>> In an email earlier this year (see below) we wanted to poll interest for >>> another installment of EPIQ. >>> From your feedback, it was clear that co-locating it with SIGCOMM would >>> be too early. >>> >>> As such, we are now planning to submit a workshop proposal for CoNEXT >>> 2021, which will take place in December. >>> There is no guarantee yet that the workshop will be approved, but given >>> our good track record we're hopeful our proposal will be accepted. >>> >>> We will of course follow this up with an official announcement in that >>> case, >>> but we wanted to give everyone a heads-up ASAP so you might start >>> preparing possible submissions. >>> >>> One final note is that, since another QUIC-related workshop (QUIPS [1]) >>> will not be organized again this year, >>> we will be putting additional emphasis on attracting work on QUIC's >>> security and privacy aspects for EPIQ. >>> This is aided by Christopher Wood from Apple joining the team. >>> >>> If you have any questions or remarks, please let us know! >>> >>> [1]: https://www.ndss-symposium.org/ndss2020/cfp-quips-workshop/ >>> >>> With best regards, >>> Robin, Lars, Jörg and Chris >>> >>> >>> On Tue, 26 Jan 2021 at 18:40, Robin MARX wrote: >>> >>>> Hello all, >>>> >>>> With this email, we would like to gauge the interest for a new edition >>>> of the academic EPIQ workshop in 2021. >>>> >>>> For those unfamiliar, the Workshop on the Evolution, Performance, and >>>> Interoperability of QUIC (EPIQ) >>>> is an academic publication and discu
Re: A side meeting on OpenSSL's plans about QUIC
Hello Rich, I'm wondering if you could give a bit more details about the expected outcome of this meeting? IIUC, most people in the QUIC wg at least seem to be of the same opinion that the OpenSSL plans are bad; I'm not sure IETF people (and even most other QUIC implementers/users) need (more) convincing of this/repeating of arguments? On the other hand, there doesn't seem to be an *active* effort to include OpenSSL people in the meeting (as mentioned on the quicdev slack yesterday). As such, I'm wondering what this potential echo-chamber aims to accomplish? Prepare an "official statement" of sorts? Initiate a more formal liaison relationship with the OMC? Is it the place of the IETF to "tell" other projects what to do? Ratify the switch to quictls and discuss plans for long-term maintenance? Discuss the future of TLS use in QUIC v2? Having a more concrete grasp on the goals would help me at least to better prepare for this potentially crucial meeting. Practical note for others: the time of the meeting seems to have changed yesterday, make sure you update your agendas (the timing in the trac seems correct/consistent with the changed ics). Thanks and with best regards, Robin On Tue, 2 Nov 2021 at 19:13, Salz, Rich wrote: > As you might know, the OpenSSL Management Committee (OMC) has released > their requirements for upcoming releases [1]. It has been met with a great > deal of community pushback, some of which I summarized [2]. > > > > A group of us are organizing a side meeting on Weds 16:30-20:00 UTC. You > can find the logistics here [3]. Agenda and moderator will be posted soon. > The meeting will be recorded. > > > > I know this is cross-posted to two very active lists. Please take care > when replying, or save it for the meeting :) > > > > [1] https://www.mail-archive.com/openssl-project@openssl.org/msg02585.html > > [2] > https://mta.openssl.org/pipermail/openssl-project/2021-October/002777.html > > [3] https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#point3 > > > > > > > > > -- 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
Re: [TLS] A side meeting on OpenSSL's plans about QUIC
Hello Rich, I'm wondering if you could give a bit more details about the expected outcome of this meeting? IIUC, most people in the QUIC wg at least seem to be of the same opinion that the OpenSSL plans are bad; I'm not sure IETF people (and even most other QUIC implementers/users) need (more) convincing of this/repeating of arguments? On the other hand, there doesn't seem to be an *active* effort to include OpenSSL people in the meeting (as mentioned on the quicdev slack yesterday). As such, I'm wondering what this potential echo-chamber aims to accomplish? Prepare an "official statement" of sorts? Initiate a more formal liaison relationship with the OMC? Is it the place of the IETF to "tell" other projects what to do? Ratify the switch to quictls and discuss plans for long-term maintenance? Discuss the future of TLS use in QUIC v2? Having a more concrete grasp on the goals would help me at least to better prepare for this potentially crucial meeting. Practical note for others: the time of the meeting seems to have changed yesterday, make sure you update your agendas (the timing in the trac seems correct/consistent with the changed ics). Thanks and with best regards, Robin On Tue, 2 Nov 2021 at 19:13, Salz, Rich wrote: > As you might know, the OpenSSL Management Committee (OMC) has released > their requirements for upcoming releases [1]. It has been met with a great > deal of community pushback, some of which I summarized [2]. > > > > A group of us are organizing a side meeting on Weds 16:30-20:00 UTC. You > can find the logistics here [3]. Agenda and moderator will be posted soon. > The meeting will be recorded. > > > > I know this is cross-posted to two very active lists. Please take care > when replying, or save it for the meeting :) > > > > [1] https://www.mail-archive.com/openssl-project@openssl.org/msg02585.html > > [2] > https://mta.openssl.org/pipermail/openssl-project/2021-October/002777.html > > [3] https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#point3 > > > > > > > > > -- 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: qlog: new streaming serialization format
Hello all, Thanks to everyone who provided feedback on the github issue. We have now released a new draft of the qlog main schema detailing the new streaming format [1]. qvis [2] has also been updated to support the new approach, so you can load files using the new format/extension. If you encounter any issues, please let me know. I will be available during the hackathon next week for people who want to implement this new setup and have questions/find bugs/etc. I am also open to discuss qlog/qvis support for other emerging use cases, such as multipath, masque, webtransport, etc. if people are interested. [1]: https://www.ietf.org/id/draft-ietf-quic-qlog-main-schema-01.html [2]: https://qvis.quictools.info/ With best regards, Robin On Wed, 20 Oct 2021 at 16:19, Robin MARX wrote: > Hello everyone, > > As discussed during IETF 111, we are looking to update qlog to move to a > new streaming serialization format. > > The current version uses the "Newline Delimited JSON" (NDJSON) format for > event streaming, which, while it works well, is not an official standard > (in the IETF or elsewhere). > > As such, it was proposed we move to the "JSON text-sequences" format > defined in RFC 7464 [1]. json-seq separates each record (qlog event in our > case) with the Record Separator character (\x1E) and a \n at the end. As > such, it should be easy to update an existing NDJSON implementation (as it > just requires outputting one additional character per event). > > We have prototyped and tested this approach in qvis and various other > tools like jq and the early outcomes are looking good [2]. > > As such, we will be preparing a PR and associated draft-01 for IETF 112 > that introduces this change. > > In the meantime, it would be great if people interested in event streaming > or with existing NDJSON qlog stacks could look at the proposal/early > results [2] and provide feedback. > > [1]: https://datatracker.ietf.org/doc/html/rfc7464 > [2]: https://github.com/quicwg/qlog/issues/172 > > > With best regards, > the qlog editors > > P.S. note that we also still plan to keep the normal JSON non-streaming > format intact, leading to two "main" formats defined in the spec: 1) normal > JSON and 2) JSON text sequences. > > -- > > 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 > > > -- 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
qlog: new streaming serialization format
Hello everyone, As discussed during IETF 111, we are looking to update qlog to move to a new streaming serialization format. The current version uses the "Newline Delimited JSON" (NDJSON) format for event streaming, which, while it works well, is not an official standard (in the IETF or elsewhere). As such, it was proposed we move to the "JSON text-sequences" format defined in RFC 7464 [1]. json-seq separates each record (qlog event in our case) with the Record Separator character (\x1E) and a \n at the end. As such, it should be easy to update an existing NDJSON implementation (as it just requires outputting one additional character per event). We have prototyped and tested this approach in qvis and various other tools like jq and the early outcomes are looking good [2]. As such, we will be preparing a PR and associated draft-01 for IETF 112 that introduces this change. In the meantime, it would be great if people interested in event streaming or with existing NDJSON qlog stacks could look at the proposal/early results [2] and provide feedback. [1]: https://datatracker.ietf.org/doc/html/rfc7464 [2]: https://github.com/quicwg/qlog/issues/172 With best regards, the qlog editors P.S. note that we also still plan to keep the normal JSON non-streaming format intact, leading to two "main" formats defined in the spec: 1) normal JSON and 2) JSON text sequences. -- 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
Re: EPIQ Workshop 2021
Hello everyone, Just a small update on the upcoming EPIQ workshop, which will be co-located with the CoNEXT conference in December. The paper and poster submission deadline has been extended from September 17 (this Friday) to September 24 (next week Friday, Anywhere-on-Earth), to give you all a bit more time to submit interesting work. All other information can still be found on the web page: https://epiq21.github.io Looking forward to reading lots of interesting stuff, Robin, Chris, Lars and Jörg On Tue, 20 Jul 2021 at 14:35, Robin MARX wrote: > Hello everyone, > > I am happy to announce that the EPIQ workshop's 3rd installment has now > been confirmed for CoNEXT 2021! > > The main goal of the workshop is to provide a venue for discussion on all > things QUIC and related technologies (e.g., HTTP/3), between both academia > and industry. > Next to typical research reports, we encourage the submission of early > work and results, brave new ideas and reproduced results from earlier work. > > Besides paper and poster discussions, we also plan to have a keynote > speaker and potentially a panel discussion. > I will be reaching out to some people about this in the coming weeks, but > if you feel you can provide an interesting keynote or you would be an > engaging panelist, please let us know! > > > Submission deadline is Friday *September 17*, with the workshop taking > place entirely online on Monday *December 6*. > Please find more information at https://epiq21.github.io > > > Hoping to receive an abundance of interesting work, > Robin, Lars, Jörg and Chris > > > On Thu, 10 Jun 2021 at 16:59, Robin MARX wrote: > >> Hello all, >> >> I wanted to send a small update regarding the academic EPIQ workshop. >> >> In an email earlier this year (see below) we wanted to poll interest for >> another installment of EPIQ. >> From your feedback, it was clear that co-locating it with SIGCOMM would >> be too early. >> >> As such, we are now planning to submit a workshop proposal for CoNEXT >> 2021, which will take place in December. >> There is no guarantee yet that the workshop will be approved, but given >> our good track record we're hopeful our proposal will be accepted. >> >> We will of course follow this up with an official announcement in that >> case, >> but we wanted to give everyone a heads-up ASAP so you might start >> preparing possible submissions. >> >> One final note is that, since another QUIC-related workshop (QUIPS [1]) >> will not be organized again this year, >> we will be putting additional emphasis on attracting work on QUIC's >> security and privacy aspects for EPIQ. >> This is aided by Christopher Wood from Apple joining the team. >> >> If you have any questions or remarks, please let us know! >> >> [1]: https://www.ndss-symposium.org/ndss2020/cfp-quips-workshop/ >> >> With best regards, >> Robin, Lars, Jörg and Chris >> >> >> On Tue, 26 Jan 2021 at 18:40, Robin MARX wrote: >> >>> Hello all, >>> >>> With this email, we would like to gauge the interest for a new edition >>> of the academic EPIQ workshop in 2021. >>> >>> For those unfamiliar, the Workshop on the Evolution, Performance, and >>> Interoperability of QUIC (EPIQ) >>> is an academic publication and discussion venue for all things related >>> to QUIC. >>> It has been organized twice in the past three years, >>> first co-located with CoNEXT in 2018 [1] and second with SIGCOMM in 2020 >>> [2]. >>> >>> A third edition was originally planned in 2019, but was unable to >>> continue due to a lack of work submitted for review. >>> While the academic QUIC community has become more active and a repeat of >>> this scenario seems unlikely, >>> we would still like to gauge concrete interest before committing to >>> organizing a new edition. >>> >>> As such, if you are performing QUIC-related work and would likely target >>> EPIQ as a publication venue, >>> please contact (one of) us via private message (see emails in CC). >>> Please also indicate whether you would prefer co-location with SIGCOMM >>> (summer 2021) or CoNEXT (winter 2021). >>> There is no requirement to specify the precise subtopic of research >>> and indicating interest of course does not imply a commitment to >>> actually submit work. >>> >>> Please let us know by Tuesday February 2nd, as the SIGCOMM Workshop >>> submission deadline is February 5th. >>> If interest is deemed too low or the
Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt
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: > Date: 2021年8月13日(金) 14:53 > Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt > To: Jana Iyengar , Kazuho Oku > > > > 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 > -- 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
Re: [Ext] Consensus call for qlog serialization format (issue #144)
he canonical interoperable format. This email >> seeks to establish consensus for this. If you have comments, for or >> against, please respond on the issue. The call will run until EoD August 9 >> 2021. >> > >> >> >> The call asked whether the (now "a") JSON serialization format will be >> the canonical interoperable format. That is quite different than "including >> at least one serialization format". As a concrete example: >> >> - The JSON serialization says that numbers such as packet_number may be >> represented as a number or a string >> >> - The data format says that the numbers such as packet_number are uint64 >> > >> If the JSON serialization format is the canonical interoperable format, >> and I'm writing a CBOR emitter, I would be allowed to write packet_number >> as a number or string because both could convert to JSON. However, if the >> data format is the canonical interoperable format, I would only be able to >> write it as a number. >> >> Thus, it is critical for interoperability between formats to specify if >> the data definition is canonical, or if the JSON serialization is >> canonical. If the latter, there really is no need for the data definitions >> at all; if this choice is made, interoperability would be more likely if >> the data definitions were removed. >> >> I hope this helps clarify why the WG needs to choose one or the other. >> > > Thanks for the additional commentary. I fear my use of canonical hasn't > helped clarity much (blame my co-chair for allowing me to use big words > :-)). > > The adopted qlog documents included a TypeScript-based data model (schema) > and a JSON serialization. There have been some discussions about changing > either of these. As you mentioned upthread, the two are associated. In an > attempt to keep discussions focused, we've somewhat avoided mentioning the > schema. The aim of finding consensus on the serialization format was so > that we could use that as input into deciding on schema definition. Picking > JSON for serialization would, hypothetically speaking for now, allow us to > rewrite the schema in CDDL. Using an IETF format for schema definition > would assuage some of the concerns that have been expressed about > Typescript or other options. And I anticipate a schema rewrite would > require the WG tackle some of the thornier issues in good time. Speaking > personally, I think that nailing down JSON as the working format du jour > will allow us to tackle data definition aspects that have been hanging over > the spec for a while. > > qlog has an objective to support alternative serializations formats and > robust transformations between them. If I understand your comments > correctly. There's an argument to say we might be approaching things > backwards and that the group should pick a data definition language first, > and then the serialization stuff might just come out in the wash. It's a > bit chicken and egg. Given we have interoperability today between QUIC > implementations generating qlogs in JSON and tools consuming JSON, for many > people the decision about data definition is of less immediate practical > importance. But that's not to downplay the long term importance of creating > a robust data definition. > > Speaking as a co-chair, getting clear consensus about the topic of schema > and serialization is important at this stage of the document's lifecycle. I > want to make sure we're asking the right questions now, and we understand > the potential impacts of things we might be trying to defer. So thanks for > picking at this. Does the intent to revist (soon) the qlog schema and > (possibly) extract the serialization address some of your concerns? Is > there a clearer way we could articulate the question to ensure the WG > understands what it is agreeing to? > > Cheers, > Lucas > > -- 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
Re: EPIQ Workshop 2021
Hello everyone, I am happy to announce that the EPIQ workshop's 3rd installment has now been confirmed for CoNEXT 2021! The main goal of the workshop is to provide a venue for discussion on all things QUIC and related technologies (e.g., HTTP/3), between both academia and industry. Next to typical research reports, we encourage the submission of early work and results, brave new ideas and reproduced results from earlier work. Besides paper and poster discussions, we also plan to have a keynote speaker and potentially a panel discussion. I will be reaching out to some people about this in the coming weeks, but if you feel you can provide an interesting keynote or you would be an engaging panelist, please let us know! Submission deadline is Friday *September 17*, with the workshop taking place entirely online on Monday *December 6*. Please find more information at https://epiq21.github.io Hoping to receive an abundance of interesting work, Robin, Lars, Jörg and Chris On Thu, 10 Jun 2021 at 16:59, Robin MARX wrote: > Hello all, > > I wanted to send a small update regarding the academic EPIQ workshop. > > In an email earlier this year (see below) we wanted to poll interest for > another installment of EPIQ. > From your feedback, it was clear that co-locating it with SIGCOMM would be > too early. > > As such, we are now planning to submit a workshop proposal for CoNEXT > 2021, which will take place in December. > There is no guarantee yet that the workshop will be approved, but given > our good track record we're hopeful our proposal will be accepted. > > We will of course follow this up with an official announcement in that > case, > but we wanted to give everyone a heads-up ASAP so you might start > preparing possible submissions. > > One final note is that, since another QUIC-related workshop (QUIPS [1]) > will not be organized again this year, > we will be putting additional emphasis on attracting work on QUIC's > security and privacy aspects for EPIQ. > This is aided by Christopher Wood from Apple joining the team. > > If you have any questions or remarks, please let us know! > > [1]: https://www.ndss-symposium.org/ndss2020/cfp-quips-workshop/ > > With best regards, > Robin, Lars, Jörg and Chris > > > On Tue, 26 Jan 2021 at 18:40, Robin MARX wrote: > >> Hello all, >> >> With this email, we would like to gauge the interest for a new edition of >> the academic EPIQ workshop in 2021. >> >> For those unfamiliar, the Workshop on the Evolution, Performance, and >> Interoperability of QUIC (EPIQ) >> is an academic publication and discussion venue for all things related to >> QUIC. >> It has been organized twice in the past three years, >> first co-located with CoNEXT in 2018 [1] and second with SIGCOMM in 2020 >> [2]. >> >> A third edition was originally planned in 2019, but was unable to >> continue due to a lack of work submitted for review. >> While the academic QUIC community has become more active and a repeat of >> this scenario seems unlikely, >> we would still like to gauge concrete interest before committing to >> organizing a new edition. >> >> As such, if you are performing QUIC-related work and would likely target >> EPIQ as a publication venue, >> please contact (one of) us via private message (see emails in CC). >> Please also indicate whether you would prefer co-location with SIGCOMM >> (summer 2021) or CoNEXT (winter 2021). >> There is no requirement to specify the precise subtopic of research >> and indicating interest of course does not imply a commitment to actually >> submit work. >> >> Please let us know by Tuesday February 2nd, as the SIGCOMM Workshop >> submission deadline is February 5th. >> If interest is deemed too low or the workshop is not accepted at SIGCOMM, >> we will postpone the workshop to another conference (likely CoNEXT) or >> next year. >> >> With best regards, >> Robin Marx (joining the team this year), Lars Eggert and Jörg Ott >> >> >> [1]: https://conferences2.sigcomm.org/co-next/2018/#!/workshop-epiq >> [2]: https://conferences.sigcomm.org/sigcomm/2020/workshop-epiq.html >> >> -- >> >> dr. Robin Marx >> Postdoc researcher - Web protocols >> Expertise centre for Digital Media >> >> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >> >> www.uhasselt.be >> Universiteit Hasselt - Campus Diepenbeek >> Agoralaan Gebouw D - B-3590 Diepenbeek >> Kantoor EDM-2.05 >> >> >> > > -- > > 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 > > > -- 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
Re: Multi-path QUIC Extension Experiments
Hello Yunfei, Thanks for your extended explanations on Multipath HoL-blocking and especially: > I think the stream dependencies you mentioned here is a great point. In our implementation, we introduced a stream-priority based reinjection which tries to address such dependency (There is a figure in the material that Yanmei sent). But we haven't tried when each stream is limited to a single path. In our case, streams are distributed on multiple paths. I would definitely want to hear more about the application you are dealing with, and maybe for wired transport, such a design is needed. This is exactly what I was trying to explore in my previous mail. You're basically intentionally causing (or perhaps risking?) HOL blocking because you split a single stream over multiple paths. As noted by Christian with the 'equal cost multipath', this can have bandwidth usage benefits, but only if paths are usable/similar. If not, HOL blocking might undo all the benefits you get from this setup (and using a single path per stream would be better). So my question was: where is the inflection point where you might decide to switch modes? At which parameters is one better than the other? I'd hoped you would have experimented with the fixed-path-per-stream setup to get some insight into this. In my mind, the idea of doing a purely transport-level multipath scheduler (i.e., without taking into account application layer streams / data dependencies / etc.) has historically made some sense for TCP / for completely separated stacks, as the transport didn't have that type of information available. It is however utterly strange to me that this approach would continue for QUIC (at least in endpoint multipath, not things like in-network aggregators that have been discussed), where we have clear splits between streams and (hopefully) already some type of prioritization information for each stream. For QUIC, I'd expect one-path-per-stream to be the default, with multiple-paths-per-stream to be an edge case if you have a single, high-traffic stream (which I do assume is your situation with a video stream). With best regards, Robin On Tue, 20 Jul 2021 at 09:15, Lars Eggert wrote: > On 2021-7-20, at 1:19, Roberto Peon wrote: > > > > If we have to send data along a path in order to discover properties > about that path, then sending less data on the path means discovering less > about that path. > > > > The ideal would be to send *enough* data on any one path to maintain an > understanding of its characteristics (including variance), and no more than > that, and then to schedule the rest of the data to whichever path(s) are > best at the moment. > > ^^^ This. > > Because the Internet has no explicit network-to-endpoint signaling, an > endpoint must build its understanding of the properties of a path by > exercising it, and specifically exercising it to a degree that causes > queues to form (to obtain "under load" RTTs, see bufferbloat) and > congestion loss to happen (to obtain an understanding of available path > capacity.) Some people have called this "putting pressure on a path". > > There has been a long-standing assumption that if you exercised a path in > the (recent) past you can probably assume that the properties haven't > changed much if you want to start exercising it again. This is why > heuristics like caching path properties (RTTs, etc.) are often of benefit - > often, but not always, and maybe never in some scenarios (e.g., > overcommitted CGNs.) > > There has been some work on this in the past for MPTCP. For example, on > mobile devices - which most often have multiple possible paths to a > destination via WiFi and cellular - exercising multiple paths comes at a > distinct increase in energy usage. So you need a heuristic to determine if > the potential benefit of going multipath is worth the energy cost of > probing multiple paths before you do so. > > Thanks, > Lars > > -- 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
Re: Multi-path QUIC Extension Experiments
Hello Yanmei, Thanks for the additional results on an interesting topic. I'm looking forward to reading the SIGCOMM paper. I was a bit surprised to (apparently) see HOL blocking mentioned as a major issue, as that's one of the things QUIC aims to be better at than TCP. It's a bit difficult to understand from the slides, but it seems like you're sending packets for a single stream (Stream ID 1 in the diagrams) on both the slow and fast path, which would indeed induce HOL blocking. Consequently, I was wondering what the practical reasons are for you to multiplex packets for a single stream over multiple paths, as opposed to for example attaching a single stream to a single path (say: high priority streams use the fast path for all their packets). I see this mentioned a bit in the draft under "packet scheduling", where it talks about switching paths once the cwnd is full for one. That indeed leads to the behaviour seen in the slides, but that's my question: why would you take those approaches then? Are there so many cases where the additional "bandwidth" from using multiple path's cwnd for a single stream outweigh the downsides of HOL blocking? Relatedly: what are the packet loss rates you've observed on real networks? Have you experimented with e.g., tying streams to paths more closely? Does that work better or worse? Why? I'm mainly wondering how these tradeoffs evolve depending on the type of paths available and if it's possible to make a model to drive this logic. I assume there is much existing work on this for MPTCP, but I also assume some of that changes due to QUIC's independent streams / stream prioritization flexibility. Thank you in advance and with best regards, Robin On Sun, 11 Jul 2021 at 20:48, Yanmei Liu wrote: > Hi everyone, > > We have finished some experiments about deploying multi-path quic > extension(https://datatracker.ietf.org/doc/draft-liu-multipath-quic/) in > Alibaba Taobao short-form video streaming, and the experiment results are > concluded in the slides (attached file). > If anyone is interested in the experimental details about multi-path quic, > please let us know. > All the feedbacks and suggestions are appreciated! > > Best regards, > Yanmei > -- 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
Re: EPIQ Workshop 2021
Hello all, I wanted to send a small update regarding the academic EPIQ workshop. In an email earlier this year (see below) we wanted to poll interest for another installment of EPIQ. >From your feedback, it was clear that co-locating it with SIGCOMM would be too early. As such, we are now planning to submit a workshop proposal for CoNEXT 2021, which will take place in December. There is no guarantee yet that the workshop will be approved, but given our good track record we're hopeful our proposal will be accepted. We will of course follow this up with an official announcement in that case, but we wanted to give everyone a heads-up ASAP so you might start preparing possible submissions. One final note is that, since another QUIC-related workshop (QUIPS [1]) will not be organized again this year, we will be putting additional emphasis on attracting work on QUIC's security and privacy aspects for EPIQ. This is aided by Christopher Wood from Apple joining the team. If you have any questions or remarks, please let us know! [1]: https://www.ndss-symposium.org/ndss2020/cfp-quips-workshop/ With best regards, Robin, Lars, Jörg and Chris On Tue, 26 Jan 2021 at 18:40, Robin MARX wrote: > Hello all, > > With this email, we would like to gauge the interest for a new edition of > the academic EPIQ workshop in 2021. > > For those unfamiliar, the Workshop on the Evolution, Performance, and > Interoperability of QUIC (EPIQ) > is an academic publication and discussion venue for all things related to > QUIC. > It has been organized twice in the past three years, > first co-located with CoNEXT in 2018 [1] and second with SIGCOMM in 2020 > [2]. > > A third edition was originally planned in 2019, but was unable to continue > due to a lack of work submitted for review. > While the academic QUIC community has become more active and a repeat of > this scenario seems unlikely, > we would still like to gauge concrete interest before committing to > organizing a new edition. > > As such, if you are performing QUIC-related work and would likely target > EPIQ as a publication venue, > please contact (one of) us via private message (see emails in CC). > Please also indicate whether you would prefer co-location with SIGCOMM > (summer 2021) or CoNEXT (winter 2021). > There is no requirement to specify the precise subtopic of research > and indicating interest of course does not imply a commitment to actually > submit work. > > Please let us know by Tuesday February 2nd, as the SIGCOMM Workshop > submission deadline is February 5th. > If interest is deemed too low or the workshop is not accepted at SIGCOMM, > we will postpone the workshop to another conference (likely CoNEXT) or > next year. > > With best regards, > Robin Marx (joining the team this year), Lars Eggert and Jörg Ott > > > [1]: https://conferences2.sigcomm.org/co-next/2018/#!/workshop-epiq > [2]: https://conferences.sigcomm.org/sigcomm/2020/workshop-epiq.html > > -- > > dr. Robin Marx > Postdoc researcher - Web protocols > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > -- 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
Re: A question about user tracking with QUIC
Hello Stephane, Could you give more (technical) details why you feel long-lived QUIC connections can allow user tracking, and specifically in the IP-switching case? For an on-path attacker observing encrypted QUIC (at one vantage point), they shouldn't be able to (easily) correlate migrated QUIC connections as the Connection IDs change during (active) migration. For an attacker with access to the decrypted payloads, I'm not sure how QUIC differs from TCP or H3 differs from H2 in your view? With best regards, Robin On Mon, 7 Jun 2021 at 14:39, Stephane Bortzmeyer wrote: > I was thinking about the privacy risks of QUIC and there is one where > I'm not sure what to think of it, and for which I cannot find any > discussion in the archives of the WG. > > Long-term QUIC connections may enable some user tracking, even when > the user changes its IP address, without even needing HTTP cookies or > things like that. > > I am not sure it is a real problem in practice because it's not new > (HTTP/2 offered similar possibilities), there are many other ways to > track users (HTTP cookies, browser fingerprinting, Google Analytics), > and they even work cross-servers. But it can be a problem for > privacy-oriented technologies (QUIC cannot currently work over Tor but > may be in the future?) > > I do not find discussions about that. Was it considered? (If so, you > are welcome to reply "Search with mailarchive yourself" but I prefer > if it comes with URLs and/or approximate datetimes.) Is it, for > instance, a good idea to advise privacy-oriented clients to always > shut down QUIC connections when IP address changes? > > > > > > -- 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
Re: [Qlog] qlog in pcap-ng format
Hello Michael, Sorry for the late reply, but gmail decided your mail belonged in my spam folder for some unfathomable reason. I must then admit my lack of knowledge on the PCAP-NG format and its possibilities and support in e.g., open source libraries. I've added a comment/TODO for this in the issue where we're tracking the qlog serialization format at https://github.com/quiclog/internet-drafts/issues/144#issuecomment-844023310 Any initial materials you might provide for this would be most welcome. The question about what to do with the separate qlog mailing list now that we're eyeing QUIC wg adoption will be escalated to the ADs. Thanks for mentioning this. With best regards, Robin On Mon, 10 May 2021 at 16:45, Michael Richardson wrote: > > Robin MARX wrote: > > I agree there is significant overlap between PCAP and qlog > conceptually > > (though I did not know pcap was actually considered for adoption at > the > > IETF). > > Please note that pcap (legacy) is intended as Informational. > PCAP-NG (I hate "NG" for a format that is now 10 years old!), is intended > as > Standards Track. > > > However, from my understanding, the PCAP format is strongly oriented > > Your understanding is accurate for PCAP, but not for PCAP-NG. > If I had a do-over, PCAP-NG would have been pure-CBOR. > > > Finally, I've added the QUIC wg in CC, as that's where most of the > > work/discussion will likely be done in the future. > > Then, I suggest maybe the qlog ML should get killed, if you want discussion > on the QUIC list. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- 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
Re: 8999?
> > So starting a moderate > complex specification today and you have some chance for RFC 1. > At least we've got something to aim for with qlog then. On Wed, 19 May 2021 at 09:24, Magnus Westerlund wrote: > On Thu, 2021-05-06 at 10:14 -0500, Behcet Sarikaya wrote: > > I would have liked > > RFC 1 more :) > > that is the number we would brake the 4 digit RFC numbering > > > > That is comming, it is roughly 4-5 years into the future. So starting a > moderate > complex specification today and you have some chance for RFC 1. > > Cheers > > Magnus > > -- 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
Re: [Qlog] qlog in pcap-ng format
Hello Michael, Thank you for your comments. 1) The qlog drafts are set to be adopted by the QUIC wg soon and this is indeed still an open point of discussion. This is tracked at https://github.com/quiclog/internet-drafts/issues/144 with already some thoughts on the matter mentioned there. 2) I agree there is significant overlap between PCAP and qlog conceptually (though I did not know pcap was actually considered for adoption at the IETF). However, from my understanding, the PCAP format is strongly oriented around logging (full) raw packet contents with little support for omission of fields / anonymization besides rough, high-level truncation (-s, snaplen?) As such, while it would be possible to support *encrypted*-quic-with-extra-comments, it would be much more difficult to support *decrypted*-quic-with-extra-comments taking into account privacy/file size/ease of capture/... (I'm not even sure pcap allows the logging of decrypted protocol data as-is? And even if it does, is it still compatible with e.g., wireshark or other pcap tools?) Additionally, again from my understanding, pcap is a custom binary format that's not all that easy to process/use. IIUC, even tools like pyshark utilize tshark's XML output instead of parsing the PCAP itself (which has been a source of much frustration on my end...). This seems to go somewhat against one of the main goals of qlog, which is to make the creation of tools and the analysis of data easier (which is one of the main reasons to choose JSON in the first place). That being said, I'm far from an expert on PCAP/PCAP-NG and could be wrong on all these counts. Please feel free to educate me. However, if I'm not, I feel it's still best to continue qlog as a separate, complementary approach to pcaps. Finally, I've added the QUIC wg in CC, as that's where most of the work/discussion will likely be done in the future. With best regards, Robin On Sat, 8 May 2021 at 21:43, Michael Richardson wrote: > > I saw part of this presentation a few weeks ago someplace. > I just watched the SAAG recording. > > 1) I think that JSON is too verbose for this stuff, but I think that CBOR >(described by CDDL) is probably exactly right for what you are doing. > > 2) PCAP-NG, which wireshark reads/writes, and libpcap only reads, >accomodates a multitude of different streams and formats, not just >ethernet dumps. >(We have USB captures, nflog captures, and stuff all sorts of >instruments). > > PCAP and PCAP-NG are candidates for adoption by the OPSAWG, but if > QUIC would like to adopt them, that's okay with me. > > I think that there is a significant value here, particular when there may > be > a need to capture both TCP, UDP and internal logic at the same time. > Imagine something doesn't work, because something is eating UDP packets > with > a particular checksum (or ethernet CRC). It's happened more than once. > Having the internal state that says, "I retransmitted foo", and then the > capture from end A, that shows the encrypted QUIC packet going out, and > then the capture from end B, which says, "I didn't get foo, I asked for it > again" > would be very useful to see. That requires merging streams from both ends, > and interleaving actual captured traffic at the same time. > (And still doesn't require access to cleartext to debug) > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > -- > Qlog mailing list > q...@ietf.org > https://www.ietf.org/mailman/listinfo/qlog > -- 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
Re: QUIC + Noise
The prototype implementation Dirkjan mentions is related to a paper "nQUIC: Noise-Based QUIC Packet Protection" [1] that was presented at the EPIQ workshop in 2018, and which includes more details on this concept. With best regards, Robin [1]: https://eprint.iacr.org/2019/028.pdf On Wed, 21 Apr 2021 at 13:40, Dirkjan Ochtman wrote: > Since another thread (that I don't want to participate in) discussed > ideas about reusing parts of the QUIC specification without relying on > the web PKI, I thought I might mention that we have some experiments > going on in Quinn with using QUIC with the Noise protocol. As far as I > know, this has been discussed before, and there was a prototype > implementation a few years ago [1]. Find out more in the issue > discussion [2] and in the repo for the Noise plugin [3]. > > If anyone is interested in moving this forward, I'd be happy to > discuss either here (if considered on-topic), in the Quinn Matrix > channel [4] or on Slack. > > Kind regards, > > Dirkjan > > [1] https://github.com/rot256/ninn > [2] https://github.com/quinn-rs/quinn/issues/719 > [3] https://github.com/ipfs-rust/quinn-noise > [4] https://matrix.to/#/#quinn:matrix.org > > -- 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
Re: The future of qlog
litting up the QUIC and HTTP/3 events into their own separate documents (as they are now combined in a single draft). If people feel that other changes are necessary prior to considering adoption, please let us know. With best regards, Robin [1]: https://datatracker.ietf.org/meeting/110/materials/slides-110-tsvwg-sessa-61-qlog-for-ietf-transports-00 [2]: https://datatracker.ietf.org/meeting/110/materials/slides-110-iccrg-qlog-structured-endpoint-logging-for-encrypted-protocols-00 [3]: https://tools.ietf.org/html/rfc8152 [4]: https://github.com/Netflix/bbparse [5]: https://github.com/uoaerg/tcpqlog [6]: https://github.com/nrybowski/quicSim-docker [7]: https://github.com/EricssonResearch/spindump [8]: https://github.com/quiclog/internet-drafts/issues/139 [9]: https://github.com/quiclog/internet-drafts On Thu, 3 Dec 2020 at 06:14, Jana Iyengar wrote: > > Thanks again, Robin, for doing this work. > > I strongly vote for option A -- keep it in QUIC. > > I think the most value for this would be in QUIC, primarily because that's > where people are actively adopting and using it. I would be reluctant to > make this broader yet, if only because our problem at the IETF usually > isn't that we have too few people with opinions on data formats (and the > color of each field). > > Practically, we already have multiple QUIC/H3 implementations emitting > qlog - and some of them already have feedback on how to extend it to be > more useful - so I would suggest that getting meaningful implementation > experience is going to be easiest with QUIC/H3 right now. Once it's done > for QUIC/H3, I would then do the generalization after as a next step, with > other use cases if and where there's interest. RFC numbers are cheap, and > you have versioning in this thing. The split you have is fine, and it > allows you to generalize this later. But keeping this discussion local to > the QUIC WG will be super useful as a first step. > > - jana > > On Wed, Nov 25, 2020 at 4:00 PM Martin Duke > wrote: > >> Splitting HTTP/3 and QUIC into separate documents, so they can evolve >> separately makes, sense, though I would be comfortable with them both >> remaining in QUICWG for now. >> >> As an AD, I will facilitate a discussion with other areas about the main >> schema. Robin, it might be useful for you to go on a roadshow at IETF 110 >> to pitch it to other areas to see if there's wider IETF energy to pursue >> qlog extensions. If so, the case for putting the main schema outside quicwg >> is pretty strong. >> >> On Mon, Nov 23, 2020 at 12:14 PM Lucas Pardue >> wrote: >> >>> Thanks Robin! >>> >>> I have some responses in line. >>> >>> On Mon, Nov 23, 2020 at 7:05 PM Robin MARX >>> wrote: >>> >>>> Hello everyone, >>>> >>>> I was happy to see a large amount of support from you all for qlog at >>>> the QUIC wg meeting last week [0]! >>>> While it seemed there was consensus that it would benefit from a more >>>> formal adoption, it wasn't entirely clear if this should be in the QUIC wg. >>>> >>>> (I am also CC'ing the HTTP wg via Lucas Pardue, who thought this would >>>> somewhat concern them as well) >>>> >>>> To recap, qlog consists of two parts: >>>> 1) the main schema, which is protocol agnostic and mostly defines the >>>> serialization and container format [1] >>>> 2) the QUIC and HTTP/3 specific events [2] >>>> >>> >>> Yes sorry HTTP folks blame me for your additional email traffic. The >>> reason I thought the discussion on qlog was pertinent to the HTTP WG is >>> because one of the major places I've found benefit is in analyzing stream >>> multiplexing using qvis. This has particularly been useful for developing >>> an implementation of Extensible Priorities in an HTTP/3 stack. The most >>> mature way to get qlog for HTTP/2 stacks would be to define qlog schemas >>> for TCP, TLS and HTTP/2. >>> >>> There are potentially other application mappings. As was discussed at >>> the IETF 109 session, I think congestion control is going to be something >>> that benefits from logging and tooling. Is there an interest in making qlog >>> work the same for a CCA across TCP and QUIC? I suspect that might drive >>> some opinion of what to do here. >>> >>> >>>> I can see roughly 3 main options and would like additional feedback on >>>> which people want: >>>> A) Adopt both in QUIC wg for now, bring them to ~full maturity for QUI
Re: Some remarks on draft-marx-qlog-main-schema-02
m, using tables inside blocks > to 'compress' repeated data. It implements streaming on a specific level > of the schema. Using such an approach in qlog would mitigate the need of > the "optimization" section (4.3). It is up to the tooling to translate > from CBOR to JSON or any other format the user or tools can read. > > Section 5 then goes into how tools should behave, down to the use of > certain environment variables. This is needlessly restrictive and > stifles any attempt to differentiate between the multitude of tools that > could be developed. > > I hope the WG and author consider these reservations on the draft > seriously. > > Best regards, > > Pieter Lexis > > 1 - https://tools.ietf.org/html/rfc5234 > 2 - https://tools.ietf.org/html/rfc8610 > 3 - https://tools.ietf.org/html/rfc7950 > 4 - https://tools.ietf.org/html/rfc7951 > 5 - https://tools.ietf.org/html/rfc8618 > 6 - https://tools.ietf.org/html/rfc8949 > -- > Pieter Lexis > PowerDNS.COM BV -- https://www.powerdns.com > > -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
Re: EPIQ Workshop 2021
Hello everyone, Due to the limited amount of feedback we received after our previous email, and because several respondents indicated they had a preference for later in the year, we have decided to postpone the third installment of the EPIQ workshop to later this year or early next year. With best regards, Robin, Lars and Jörg On Tue, 26 Jan 2021 at 18:40, Robin MARX wrote: > Hello all, > > With this email, we would like to gauge the interest for a new edition of > the academic EPIQ workshop in 2021. > > For those unfamiliar, the Workshop on the Evolution, Performance, and > Interoperability of QUIC (EPIQ) > is an academic publication and discussion venue for all things related to > QUIC. > It has been organized twice in the past three years, > first co-located with CoNEXT in 2018 [1] and second with SIGCOMM in 2020 > [2]. > > A third edition was originally planned in 2019, but was unable to continue > due to a lack of work submitted for review. > While the academic QUIC community has become more active and a repeat of > this scenario seems unlikely, > we would still like to gauge concrete interest before committing to > organizing a new edition. > > As such, if you are performing QUIC-related work and would likely target > EPIQ as a publication venue, > please contact (one of) us via private message (see emails in CC). > Please also indicate whether you would prefer co-location with SIGCOMM > (summer 2021) or CoNEXT (winter 2021). > There is no requirement to specify the precise subtopic of research > and indicating interest of course does not imply a commitment to actually > submit work. > > Please let us know by Tuesday February 2nd, as the SIGCOMM Workshop > submission deadline is February 5th. > If interest is deemed too low or the workshop is not accepted at SIGCOMM, > we will postpone the workshop to another conference (likely CoNEXT) or > next year. > > With best regards, > Robin Marx (joining the team this year), Lars Eggert and Jörg Ott > > > [1]: https://conferences2.sigcomm.org/co-next/2018/#!/workshop-epiq > [2]: https://conferences.sigcomm.org/sigcomm/2020/workshop-epiq.html > > -- > > dr. Robin Marx > Postdoc researcher - Web protocols > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
EPIQ Workshop 2021
Hello all, With this email, we would like to gauge the interest for a new edition of the academic EPIQ workshop in 2021. For those unfamiliar, the Workshop on the Evolution, Performance, and Interoperability of QUIC (EPIQ) is an academic publication and discussion venue for all things related to QUIC. It has been organized twice in the past three years, first co-located with CoNEXT in 2018 [1] and second with SIGCOMM in 2020 [2]. A third edition was originally planned in 2019, but was unable to continue due to a lack of work submitted for review. While the academic QUIC community has become more active and a repeat of this scenario seems unlikely, we would still like to gauge concrete interest before committing to organizing a new edition. As such, if you are performing QUIC-related work and would likely target EPIQ as a publication venue, please contact (one of) us via private message (see emails in CC). Please also indicate whether you would prefer co-location with SIGCOMM (summer 2021) or CoNEXT (winter 2021). There is no requirement to specify the precise subtopic of research and indicating interest of course does not imply a commitment to actually submit work. Please let us know by Tuesday February 2nd, as the SIGCOMM Workshop submission deadline is February 5th. If interest is deemed too low or the workshop is not accepted at SIGCOMM, we will postpone the workshop to another conference (likely CoNEXT) or next year. With best regards, Robin Marx (joining the team this year), Lars Eggert and Jörg Ott [1]: https://conferences2.sigcomm.org/co-next/2018/#!/workshop-epiq [2]: https://conferences.sigcomm.org/sigcomm/2020/workshop-epiq.html -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
Re: qlog schema
Hello Martin and others, Good to hear there is a clear opinion on how to move forward with qlog within the IETF, thank you for the effort. I'm also happy it can remain in the QUIC wg for the time being. I will as proposed register a HotRFC session for IETF 110 to hopefully get some outside involvement. @Philip: I agree we shouldn't define a file format but rather a binding to JSON/NDJSON/other (binary) formats. This is what I've tried to do so far with the qlog main schema. I'm not entirely sure myself we should consider encryption/authentication of the logs as part of this endeavour, but of course that's something that can be discussed in a wider group once qlog is adopted. The plan for now is to continue development of qlog in the existing github repo at https://github.com/quiclog/internet-drafts until the documents are adopted. I suspect we'd cut a new draft-03 right before that. I would encourage interested people not to wait until then, but to already engage with the work there in the meantime. With best regards, Robin On Wed, 16 Dec 2020 at 19:14, Phillip Hallam-Baker wrote: > This is a good step. As one of the authors of the W3C log format, I think > it would have been much better to have a discussion of the log features as > part of the protocol design. There was no interest and which is why there > isn't even a proper spec. Basically, this is like SNMP and MIBs, you want > the MIBs to be developed by the groups developing the protocols. > > I would however urge that this be presented as an effort to create a > schema doe log file entries with bindings to JSON and NDJSON rather than a > log file format itself. > > It is about time that we had a cryptographic log file format that supports > modern features such as incremental encryption and authentication. The > power of one way sequences has been established by BlockChain. That is not > a framing mechanism I would want to use for a log file but it shows the > principle. > > Separating out the protocol specific schema from the framing allows > independent development of each. And yes, I do happen to have an > implementation of a log file format with cryptographic enhancements. And it > can do things like allow rapid location of a specific record range within > the log file, etc. > > Why would you want to encrypt your logs? Well, it is a question of HIPPA > and GDPR for some. But more generally, what a service can't read, a service > can't breach. If Mallet gets into my cloud, she is going to find it a lot > harder to sabotage my systems undetected if she can't read the log files > and they are in any case protected using Merkle trees. At that point, all > she can really do is to delete large chunks of log but that will leave > traces. > > Given what happened this week, given the serious breaches that will be > announced next month, demand for encrypted logs is going to come quickly > when it comes. > > The other reason to encrypt your logs is it provides you with the basis > for an encrypted persistence store with ACID properties. > > > But that is all in the future. For the time being, the best plan is to > develop one example of a decent log file using the JSON data model. If > there is interest in doing a cryptographic format, that would obviously be > a separate WG. That would focus on the format itself using HTTP/QUIC as the > paradigm from which the general case is developed. > > > On Wed, Dec 16, 2020 at 12:34 PM Martin Duke > wrote: > >> Hi Robin, >> >> Congrats on your defense! I hope to watch it soon. >> >> We had a chat about qlog at the IESG. The consensus there appears to be >> that we should plan to move forward in quicwg with both drafts rather than >> seek another venue. However, it would be valuable for you to request a >> HotRFC slot to encourage the parallel development of qlog-based standards >> in other working groups. >> >> If that's agreeable to you, feel free to proceed. >> >> Martin >> > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
Re: The future of qlog
Hello everyone, I was happy to see a large amount of support from you all for qlog at the QUIC wg meeting last week [0]! While it seemed there was consensus that it would benefit from a more formal adoption, it wasn't entirely clear if this should be in the QUIC wg. (I am also CC'ing the HTTP wg via Lucas Pardue, who thought this would somewhat concern them as well) To recap, qlog consists of two parts: 1) the main schema, which is protocol agnostic and mostly defines the serialization and container format [1] 2) the QUIC and HTTP/3 specific events [2] In theory, we could have other documents similar to [2], defining events for TCP, TLS, HTTP/2, DNS, BGP, etc. all using the same qlog main schema as a basis. This is how qlog was originally intended and hopefully someday will evolve to. For now it has focused mainly on QUIC and H3 as they were optimal experimental targets. While adopting both documents in the QUIC is possible and probably the most practical in the short term, it's not entirely clear this is the optimal path. For example, what would be the approach for defining e.g., HTTP/2 events down the line? Do this in the HTTP wg in collaboration? Or do it in QUIC as it's probably mostly the same people doing the work anyway? Even for more QUIC specific things there can be problems. For example, Ian and Matt expressed the need for broader congestion control events, yet the QUIC wg isn't chartered to really work on anything other than Reno atm. I'm not saying these are necessarily (major) issues, but I'm not experienced enough in IETF processes to know the best way forward or if these are actually problems. I can see roughly 3 main options and would like additional feedback on which people want: A) Adopt both in QUIC wg for now, bring them to ~full maturity for QUIC and H3, and then see if/how to generalize later (it seemed to me most were leaning to this side last week) B) Adopt document [2] in QUIC wg and find another place for [1], either in an existing wg or a new one via BOF by IETF 110 (what happens if that fails though?) C) Find an existing wg or do a BOF for both [1] and [2] together by IETF 110 (not sure this has enough traction outside of QUIC wg?) I'm also hoping people here can give some practical hints on how to move this forward (e.g., what do I have to do to get a document adopted etc.) A final important aspect was aptly summarized by Jana as "qvis/tooling is what people love, qlog is what people need". For those that don't know, qvis [3] is an open source set of tools that I and my team have been maintaining to visualize qlogs and other formats (such as pcaps and netlogs). The codebase is of (ahem) dubious quality and I definitely wouldn't mind extra people joining the project both for maintenance and new tool development. Another aspect is that we're currently hosting this on a university server, but will have to move to something else in 2 months. I'd prefer to not keep this tied to me personally. I'm not sure how much this can/should be tied to the IETF or QUIC wg proper, so I'd be interested in other people's opinions on how to organise qvis as well. Thanks in advance for your valuable feedback, Robin [0]: https://github.com/quicwg/wg-materials/blob/master/ietf109/minutes.md [1]: https://tools.ietf.org/html/draft-marx-qlog-main-schema-02 [2]: https://tools.ietf.org/html/draft-marx-qlog -event-definitions-quic-h3-02 [3]: https://github.com/quiclog/qvis On Thu, 5 Nov 2020 at 17:51, Robin MARX wrote: > Hello everyone, > > As you might have seen, I submitted draft-02 of the qlog format just > before the > IETF 109 cutoff [1][2]. The main change from -01 is the move back to a > simpler > default JSON serialization and explicit support for streaming logs using > NDJSON. > > A year in the making, this update reflects feedback from a considerable > adoption > and deployment experience of the format by the IETF QUIC community. Over > 60% of > active implementations currently (partially) support the format [3] and > many of > you have actively contributed to improving this project, for which I am > eternally > grateful. > > Still, with this email, I am once again asking for your support. With > draft-02, I > feel we have reached the limits of what the current team can accomplish on > its > own. There are several issues of scope and approach that would benefit > greatly > from broader discussion. The main ones are: > > 1. Should qlog focus on reflecting internal implementation events (for > example a >"packet_acked" event) or provide ways to log the protocols' wire image > (for >example the ACK frame). Or both? [4] > 2. Should qlog feature a wide range of events, each reflecting a specific > small >aspect, or rather fewer, consolidated events? How much should the qlo
The future of qlog
Hello everyone, As you might have seen, I submitted draft-02 of the qlog format just before the IETF 109 cutoff [1][2]. The main change from -01 is the move back to a simpler default JSON serialization and explicit support for streaming logs using NDJSON. A year in the making, this update reflects feedback from a considerable adoption and deployment experience of the format by the IETF QUIC community. Over 60% of active implementations currently (partially) support the format [3] and many of you have actively contributed to improving this project, for which I am eternally grateful. Still, with this email, I am once again asking for your support. With draft-02, I feel we have reached the limits of what the current team can accomplish on its own. There are several issues of scope and approach that would benefit greatly from broader discussion. The main ones are: 1. Should qlog focus on reflecting internal implementation events (for example a "packet_acked" event) or provide ways to log the protocols' wire image (for example the ACK frame). Or both? [4] 2. Should qlog feature a wide range of events, each reflecting a specific small aspect, or rather fewer, consolidated events? How much should the qlog events reflect the exact protocol mechanics/internal details? [5] 3. What are the privacy and security best practices for this kind of endpoint logging and how can/should they be enforced? 4. Is qlog as a concept more widely applicable to other protocols than just QUIC/H3? If yes: what does that mean exactly? The answers to these and other questions will follow largely from concrete future applications and use cases people have in mind. This in turn will influence if, how and where we continue work on qlog. Early on, we already discussed wider applications for the qlog concept in tsvarea [6]. However it was decided to first get qlog implementation experience for QUIC/H3, which I believe has now happened. However, this also means qlog now has the most direct value for QUIC/H3 and it feels natural to me to first hear the perspective of the QUIC wg on its future. I can see many possible ways forward, including: adopting this within the QUIC wg, adopting this in another wg, doing a BoF to try and form a new wg, create a design team, organize a single interim session to decide the main points, switch to maintenance mode and use qlog as-is, etc. I have requested an "if time permits" slot for the IETF 109 QUIC meeting in two weeks to get a feel for what people think. This email is to have a backup in case we don't have time then and so people can prepare (or already share) their opinion (if any). Thanks again to everyone who has already contributed to qlog and with best regards, Robin [1]: https://tools.ietf.org/html/draft-marx-qlog-main-schema-02 [2]: https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-02 [3]: https://qlog.edm.uhasselt.be/anrw/files/DebuggingQUICWithQlog_Marx_final_21jun2020.pdf [4]: https://github.com/quiclog/internet-drafts/issues/53 [5]: https://github.com/quiclog/internet-drafts/issues/85 [6]: https://www.youtube.com/watch?v=LiNLz1QuT0s&t=3233 -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
Re: Preparing for discussion on what to do about the multipath extension milestone
Hello all, I don't want to get too deep into this, as I don't have enough experience with multipath to have a well-founded opinion. With regards to Lucas' questions on interfacing HTTP2/3 priorities with multipath TCP/QUIC, I am aware of several recent works that have looked at this problem (e.g., [1], [2], [3]). I'm not entirely convinced of their results, methodology or conclusions myself, but they all claim to see benefits for the Web page loading use case. I share the concern that this specifically is a generally difficult and largely unsolved (research) problem and that APIs/interfaces for exposing the full power of multipath to the application layer will be difficult to create. Then again, the same can be said for exposing QUIC-layer scheduling to the application layer, and we seem to be happy to stick our heads in the sand for that... I also feel it's important to make the clear distinction between general multipath scheduling (what I feel is mostly what Olivier is describing) and "stream-aware" scheduling (what I'd call "prioritiy-driven", and my remarks above allude to), where I get the impression the first is a generally solved problem for MPTCP with a large body of research (and deployment experience) that can be relatively directly re-used for MP-QUIC. As a personal critical remark on the use of multipath for the Web browsing use case, I feel that the wider Web performance community in general is of the opinion that the network itself matters less these days, and that the (ab)use of e.g., JavaScript frameworks, loading of (too) large images, etc. has a much more profound impact on the observed user performance than (limited) network bandwidth, especially on slow mobile devices with limited processing capabilities. As such, I too posit that we should not consider Multipath just or primarily for the HTTP use case (or hinge it on its application in that area), but as a property of the general purpose transport that QUIC aims to be. In this context, like Olivier, I feel most of the lessons learned from MPTCP can be transposed to QUIC, including its deployment experience. If true, the question of the usefulness of MPQUIC devolves into the usefulness of MPTCP, which I think the past decade of research and implementation has shown to be considerable. As such, I wonder if the amount of work necessary for MPQUIC isn't being overestimated, as well as if (some of) the "outstanding questions" really are unanswered. Robin [1] : A stream-aware multipath quic scheduler for heterogeneous paths - Rabitsch et al. - https://dl.acm.org/doi/pdf/10.1145/3284850.3284855 [2] : SRPT-ECF: challenging Round-Robin for stream-aware multipath scheduling - Jonglez et al. - https://hal.inria.fr/hal-02570686/document [3] : PriorityBucket: A Multipath-QUIC Scheduler on Accelerating First Rendering Time in Page Loading - Shi et al. - https://dl.acm.org/doi/pdf/10.1145/3396851.3402923 On Wed, 30 Sep 2020 at 12:50, Lucas Pardue wrote: > It's this special sauce that concerns me. > I don't know how I'd objectively measure that the MP-QUIC design and all > the implementation effort would actual result in improvement. For instance, > more bandwidth via aggregation can still be misused; some types of streams > will be more latency sensitive than others. Putting the decision making > into the transport library could also be seen as black box. > > I also want to draw some parallels between uniflows and the HTTP/2 > priority tree. The tree was a fully expressive model that allowed a client > to hint to the server about the relationship between streams. The problem > of actioning this signal was left up to the server. Deployment experience > reveals that getting this well-tuned, just for a single TCP connection, is > hard. Some implementers just never got around to fixing some serious and > easily detectable performance problems. > > Presenting a bunch of uniflows to a sever and leaving it responsible for > using them properly seems to me quite a similar problem. > > Lucas > > >> -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
[android-developers] Streaming encoded video via RTP 2
This is actually a post that belongs in this thread : http://groups.google.com/group/android-developers/browse_thread/thread/e677b894b4c502d9/5eb4d892c12a8393 But since it is closed I will open a new thread. If a moderator could add this post to the above thread and re-open it, that would be appreciated. As you can read in the other thread, no real solutions were given to the streaming of RTP video problem I posted about a year ago. Since then, I've been getting a lot of mails from people who are trying to do the same thing and I always have to give them the same answer. Tired of re-typing the same mail, I'm posting our experiences here for reference. I'm going to disappoint you from the start: we did NOT find a full solution to the problem. We were able to stream audio and video from the phone to a desktop pc and decode/play it there, but the other way around was impossible. Our project switched to a Windows XP mobile tablet pc. I'll explain what we did to stream to the PC. The method with the socket to send the data to native code worked perfectly. Then, in native code, we needed to buffer the data, extract h.263 frames, which we could then pack into RTP packets and send over the network. This works because android tries to save the video as an .mp4 file, which is basically just a container for unmodified h.263 data. Android writes almost all the mp4 data at the END of the file, so don't trouble yourself with that if you're constantly streaming the video. All you need to do is cut off the first few bytes of .mp4 data at the very beginning (can't remember the exact number, but it's always a fixed number of header bytes). After this, it's all just h.263 data. This is a well documented format which you can write a simple parser for yourself. All we did was buffer and parse the frames to retrieve the size in bytes of the current frame. If this amount of bytes was present in the buffer, we knew we had read a full frame and could send it in an RTP packet. (I have some of our code for parsing the h.263 data. You can contact me if you want this code. But attention! it won't be directly usable code as it is an excerpt from our framework and is just intended to give you the general idea and insight in how h.263 data can be interpreted). It should be clear that this is if you capture video ONLY. If you would capture audio and video in the same capturer, the h.263 data would be interjected with audio data in an undefined manner (unless google documented it somewhere, but this was not the case at the time we think). It is possible to capture audio seperately however and use the same logic as we did for the video stream. The big problem then will be to sync audio and video, especially if you want to use RTP for transmission. We did all this natively on android in C++ because we wanted to test our RTP library and network parameters. If you just want to send video to your pc, you can just parse the h.263 frames on your computer to feed to a decoder and don't bother yourself with putting everything in RTP packets on android. Then you can just use a TCP socket connected to the server PC and send all video data directly to it. However, this should only be used in research or personal project settings and is not fit for commercial or serious applications! This all is still a non-optimal method which will have some delay and processing overhead, so don't expect miracles. As for the receiving of video on the android, we simply couldn't get it working. Android can only play video FILES, so the only way to do this would be to write the received data to a file and fake android into playing it. And here is the big problem: we could ignore the .mp4 data for sending the data, but for playing a file... android really needs the data. And this means we would have to fake it, a very troublesome process. We didn't even finish our attempts at faking mp4 header data. There is a possibility to play video from a stream of RTSP which you should definitely look into if you don't need to control SIP or RTP data yourself but just want to playback video. I hope this was informative and if there are any more questions you can always contact me at my email address. Happy coding! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Multiple SUM in query
Since I can't seem to find the answer on google, nor in the docs, I hope someone here can help me. Whenever I try to do a query with more then 1 SUM-field in it, it will only return the first SUM-field, not the other ones in its results. So for instance : SUM( amount1 ) as amountOne, SUM( amount2 ) as amountTwo + group on year will only return amountOne as result. When I do : SUM( amount2 ) as amountTwo, SUM( amount1 ) as amountOne + group on year it will only return amountTwo. Anyone got an idea why this behaviour occurs and how to fix it? We would be most grateful because it's quite urgent for a school project. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
[android-developers] Re: Streaming encoded video via RTP
First of all, we have no idea whatsoever on how to access the opencore functionality from our native code (or from java). We found a lot of posts from people saying they are using the encoders/decoders directly, or trying to add extra format-support etc. but nowhere do we find documentation on even the most basic things for using the native opencore API. If you could tell us how to directly access the encoders for example, that would take us a LONG way already. As for RTP we really need to be in control of what is in the packages and how they are sent. Part of the research is working with a proxy that'll filter certain packets based on the available bandwidth and other resources of the network, so we really want full control over the RTP functionality on all ends. This means other RTP implementations are out of the question for us. We have been making some progress though. At the moment we are able to stream speex-encoded audio to the device, decode it (this step is very slow on emulator, but fast enough on the device itself) and play it as a .wav file (putting a dummy wav-header before the actual data seems to work just fine). We use the methode described here for good buffered playback from socket : http://blog.pocketjourney.com/2008/04/04/tutorial-custom-media-streaming-for-androids-mediaplayer/ (so the inputstream is not from an URL but from our native socket and we don't play .mp3 but .wav). As for video we can now transmit from the device to the desktop using the ParcelFileDescriptor-method. Native code on the device wraps the data in rtp-videopackets. On the desktop we buffer the packets and parse the h.263 headers until a full frame has arrived and then show it (the first 32 bytes android writes are the 3gpp header, just ignore it, the h.263 frames start right after that without .3gpp things in the videodata). While this gives us live video-feed (with minor delay) it is far from optimal for our research (no correct timing information in the rtp-packets for instance, making lipsync difficult etc.). We expect that sending audio wouldn't be that different from sending video, but for the moment we don't have a working amr-decoder on the desktop so we can't test it yet. Receiving video is going to be the hard one with these methods. For audio we can use the simple .wav format, but .3gpp is considerably more complicated and we think it's almost impossible to replicate for a live stream such as ours (if you can, please prove us wrong. Our main concern at the moment is the stsz-atom with the timing info). I hope this can help some others working on the same problem, but these solutions are NOT optimal. If anyone can tell me how to use the opencore functionality we will probably be able to find much better methods and share them. Thanks in advance and thanks to those who replied. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Streaming encoded video via RTP
Hello, For a research project we need to capture video on the HTC magic and transmit this video over a network to other devices, both HTC magic's and desktop pc's (which have their own implementations of the codecs). For the transmission over the network we are using some of our own native libraries, which have all compiled fine and work. These libraries work via the RTP (Real time transfer) protocol. This poses a significant problem because RTP expects detailed information about the contents of each packet (exact timestamp, sampling rate, which part of which frame is in each packet etc.) So we tried the method described at http://www.mattakis.com/blog/kisg/20090708/broadcasting-video-with-an This appears the only way to get the MediaRecorder to send it's data to our native application. So we run a server-socket on the native side, send MediaRecorder output to a FileDescriptor of a javasocket. The native side does receive data. 2 problems however : 1. Like said in the blogpost : header information etc. is not filled in, so if we write the data to file from the native-side, it's not playable. 2. The socket we write to is TCP, so a stream implementation. So there is no clear way to know where each frame begins and ends (because the data comes in continuously). And that's the main problem : we can't package the data in good RTP packets for transmission! Nor can we get good information about the timing etc. So we looked into OpenCore a little bit, hoping to be able to do it through JNI-interfaces ourselves (or maybe even directly with the native implementations from our native code). This has proven a daunting task, because so little documentation can be found on these things. So the question is : Is it possible to get the encoded video (and audio) data with clear frame-separation and good timing-information for RTP transmission? (It is not an option to use anything but RTP, as the research is partly about RTP possibilities) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
