I'm not entirely sure I understand where the efficiency gains come from, or
why it's necessary to reverse the wire encoding of every single QUIC frame.
Could the same effect be achieved if the data field of the first STREAM
frame of each packet were guaranteed to start at a predefined offset?
Read
Michael is right. Lucas, it would be very much appreciated if we could hold
the meeting at the Doodle time slot, i.e. starting at 1400 UTC.
On Thu, 16 May 2024 at 15:39, Michael Eriksson wrote:
> Hi Lucas,
>
> I don't think the scheduled time slot matches the Doodle alternative. In
> my timezone
Perhaps unsurprisingly, I support the move to explicit path IDs.
On Fri, 12 Apr 2024 at 13:32, Lucas Pardue wrote:
> Hi folks,
>
> We saw extensive discussions about the use of explicit path IDs for
> Multipath over the last few months. At IETF 119, in the room there was
> strong support for mer
The current proposal (
https://datatracker.ietf.org/doc/draft-thomson-webtrans-session-limit/) for
transmitting flow control messages serializes the capsules onto the
WebTransport control stream. Since the control stream is a QUIC stream,
this means that these messages suffer from HoL blocking in t
> What I suspect in fact is that in the datacentre what most admins would
> be interested in would just be to disable header protection to make it
> easier to follow the protocol itself (e.g. observe retransmits etc)
> without risking to expose the payload, that absolutely nobody wants to
> see the
Plain-text communication was an explicit anti-goal in the design of QUIC.
That said, there was a QUIC extension that disables encryption after the
handshake, but it never moved past a -00 version, and has expired a long
time ago:
https://datatracker.ietf.org/doc/html/draft-banks-quic-disable-encryp
I agree with Kazuho and Christian. There were doubts raised on this list
regarding the proposed protocol mechanism, and I'm surprised to see a
request for a provisional registration at this point, and for an individual
draft. This only seems justified if there's intent for internet-scale
deployment
ob/main/interim-18-09/minutes.md#ack-ecn---ian
>>
>>
>>> (That's my memory only, I don't think that I was involved in the design
>>> team directly.)
>>>
>>> On Wed, Nov 1, 2023, at 21:38, Marten Seemann wrote:
>>> > While looki
As I see it, the problem we're discussing here is *not* a qlog problem.
It's a general problem with the ACK delay on ACKs received in Initial and
Handshake packets, both of which might be received before processing the
transport parameters.
We discussed this in
https://mailarchive.ietf.org/arch/ms
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
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 handsh
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 rig
nd, if the frame is not
supposed to be acted upon by the client, there's no reason to use a frame
in the first place, as servers can just unilaterally decide to put the
information into the token.
On Sun, 5 Nov 2023 at 15:32, Gorry Fairhurst wrote:
> On 05/11/2023 10:04, Marten Seemann wrote
In the design of RFC 9000, frames are used to communicate information
between two endpoints. This is not what the BDP_FRAME frame does: It's only
saved by the client and echoed back to the server on a later connection. It
is questionable to me if the client’s ability to inspect (but not modify)
the
it in an
> extension, later. What we have works with what you call classic ECN, OGECN,
> but just like fine-grained timing information, we decided to defer.
> >
> > (That's my memory only, I don't think that I was involved in the design
> team directly.)
> >
>
negligible.
I wrote up an alternative encoding scheme in
https://github.com/marten-seemann/draft-seemann-quic-accurate-ack-ecn (I
currently can't submit it as a draft, since the datatracker doesn’t allow
new submissions past the deadline for 118). ECN counts were introduced in
https://github.com/q
I like Igor's idea, as it reduces the number of frames we need to define.
However, sending the address automatically has an annoying race condition
when used with multipath: A path might only work in one direction, but not
in the return direction. The NEW_OBSERVED_ADDRESS therefore needs to
identif
ever the remote address changes on a
path (e.g. due to a NAT rebinding).
We might use the value of the transport parameter to distinguish between
"I'm willing to report your address" and "I'm requesting that you send me
NEW_OBSERVED_ADDRESS frames".
I opened
I just published an I-D that defines a mechanism for QUIC endpoints to
discover their (public) IP address and helps them determine their position
in the network (e.g. if they're behind a NAT):
https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/
This is especially helpful for QUIC
The Reliable Reset draft introduces a CLOSE_STREAM frame that allows
resetting a stream at a specific offset, thereby guaranteeing the reliable
delivery of stream data up that offset.
At IETF 117, there was some discussion (mainly in AVT) about whether there
should be a method for an endpoint to a
I think RFC 9000 covers this case, albeit in a less than ideal way.
Section 20.1 defines the STREAM_STATE_ERROR: "An endpoint received a frame
for a stream that was not in a state that permitted that frame"
One could argue that this covers the case where RESET_STREAM or
STREAM_DATA_BLOCKED is rec
it's
going to send a Version Negotiation packet for.
On Sun, 23 Jul 2023 at 11:04, Lucas Pardue
wrote:
> Hey,
>
> On Sun, Jul 23, 2023 at 6:40 PM Kazuho Oku wrote:
>
>> 2023年7月22日(土) 15:24 Marten Seemann :
>>
>>> RFC 9443 defines how to demultiplex QUIC from a wh
Key updates as defined by RFC 9000 are not an optional feature. Any
implementation that doesn't implement key updates is not compliant with the
RFC and has to expect that transfers will randomly break. Even worse,
ignoring a key update won't immediately kill the connection, but will
eventually resu
RFC 9443 defines how to demultiplex QUIC from a whole range of other
protocols. Packets in the range 128..191 (i.e. all packets starting with
0b10xx) are supposed to be forwarded to RTP/RTCP.
This mostly works, since QUIC v1 packets (both short and long header)
define the "QUIC bit", the secon
hat will interact somewhat poorly with a
> protocol like QUIC that expects to be more involved in that process. It's
> worse in mode 2, which might be quite confusing with the two layers
> interacting as they do. That could stand to be made much clearer.
>
> Cheers,
> theon
I just submitted a new draft that describes how to do NAT traversal using
QUIC:
https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/
The document defines 3 distinct modes. The first mode is the simplest one,
first running ICE to completion to find a suitable path between two nodes,
a
Would there be interest in adding some automated tests to the QUIC Interop
Runner (https://github.com/marten-seemann/quic-interop-runner)? I probably
won't have the bandwidth to work on this myself, but I'd be happy to give
some pointers, if anyone is interested in creating a test.
On
It might not be safe to use the ACK Delay received in an Initial packet. An
attacker could rewrite the value such that the client's RTT estimate
becomes very close to zero, which would lead to very short retransmission
timers.
quic-go therefore neither sends nor acts upon ACK delays reported in
In
Perhaps unsurprisingly, I also support adoption.
On Wed, 5 Apr 2023 at 04:53, Lucas Pardue
wrote:
> Hello QUIC WG,
>
> During IETF 116 we discussed draft-seemann-quic-reliable-stream-reset [1]
> and the sense in the room was strong support for adoption.
>
> This is a formal adoption call that wi
For everyone not following the GitHub multipath repo, I've posted a
proposal to introduce a (as I believe) cleaner separation between Path IDs
and Connection IDs: https://github.com/quicwg/multipath/issues/214
This opens the door for a potential simplification of the packet protection
key schedule
Christian, I don't think that's correct. We discussed this during our work
on RFC 9000, and there's section 8.1 addresses exactly that problem:
> Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets. A deadl
I'm not sure I understand the motivation of this draft. Setting initial
values for initial RTT, idle timeouts etc. is already possible. How exactly
this is done will depend on the API exposed by the QUIC stack. The QUIC WG
hasn't specified any QUIC API, and different QUIC implementations expose
ver
I've updated quic-go to the new values, and I can confirm that the test
vectors are correct.
On Mon, Dec 12, 2022 at 12:42 PM Martin Thomson wrote:
> On Sun, Dec 11, 2022, at 09:54, Martin Duke wrote:
> > I would appreciate a sanity check. If anyone has tooling to re: the
> > test vectors that c
I support this change.
On Tue, Nov 8, 2022 at 12:58 PM Tommy Pauly wrote:
> I support this change as well.
>
> On Nov 8, 2022, at 3:04 AM, Ian Swett 40google@dmarc.ietf.org> wrote:
>
> I support this change.
>
> On Tue, Nov 8, 2022 at 10:07 AM Matt Joras wrote:
>
>> Hello all,
>>
>> At the
Thank you for the draft. I was wondering if this should be a QUIC frame
instead of a transport parameter.
A frame would make this more interesting for the more general case where
the set of addresses of a node is not static. Take for example a QUIC
connection between two mobile devices (where inte
t; Hi Martin,
>
>
>
> thanks for your reply. Please see below.
>
>
>
> *From: *Marten Seemann
> *Date: *Friday, 23. September 2022 at 12:24
> *To: *Mirja Kuehlewind
> *Cc: *QUIC WG
> *Subject: *Re: new draft: RELIABLE_RESET_STREAM
>
>
>
> Hi Mirja,
&
am will never be used)? Or maybe asked differently, why
>is the sender sending a reset at all?
>
>
>
> Mirja
>
>
>
>
>
>
>
> *From: *QUIC on behalf of Marten Seemann <
> martenseem...@gmail.com>
> *Date: *Friday, 9. September 2022 at 10:35
>
In RFC 9000 we defined a RESET_STREAM frame. When a stream is reset, the
receiver may deliver the reset error to the application immediately. On the
sender side, lost STREAM frames won't be retransmitted.
When building applications on top of QUIC, it is a common pattern to send
some kind of identif
I ran into an unexpected interaction between DLPMTUD and QUIC's idle
timeout in my implementation. I've implemented the "Probing using padding
data" described in the DLPMTUD draft: I send a single PING frame and then
use PADDING frames to achieve the desired probe packet size.
Assume that you're s
This is a good idea. Should be easy enough to implement.
On Tue, Jan 11, 2022 at 3:40 AM David Schinazi
wrote:
> I like this. It would be easy to implement for us, and might help a little
> bit ossification-wise.
>
> David
>
> On Mon, Jan 10, 2022 at 3:24 PM Martin Duke
> wrote:
>
>> This issue
I support adoption, with the understanding that the delta will only contain
changes necessary to achieve the intended goal of getting the network used
to multiple QUIC versions (and exercising version negotiation).
On Fri, Nov 12, 2021 at 9:51 PM David Schinazi
wrote:
> Hi Matt,
>
> Clarifying q
Hi Martin,
Thanks for writing this up. If there's interest in deploying v1 and v2 at
the same time, we could scratch the requirement to implement the version
negotiation draft. This would open us up to version "downgrade" attacks,
but given that the two versions have identical security properties
Matt shared the recording with me and I was able to watch it today. Thank
you for that.
In general, a processing time of 10 working days seems way too long to be
useful for people who want to actively participate in the work. Interim
meetings usually cause a lot of activity on the mailing list, an
Thank you for the summary. Is there a recording of the meeting? Would have
love to attend if it had been at a more suitable time.
On Fri, Apr 23, 2021 at 01:34 Matt Joras wrote:
> Hello all,
>
> As noted in previous mail, the draft minutes are available here[1]. A
> high level summary of the mee
I support adoption.
On Wed, Mar 31, 2021 at 7:07 AM Martin Thomson wrote:
> On Wed, Mar 31, 2021, at 06:38, Matt Joras wrote:
> > It is the opinion of the chairs that the delayed-ack
> > draft[1] has sufficient interest from and relevance to the WG to be
> > formally adopted.
>
> I share that op
I haven't implemented it yet in quic-go, but it's on my list. I support
adoption.
On Wed, Mar 31, 2021 at 7:08 AM Martin Thomson wrote:
> Obviously I think this is a good idea. I've implemented it and Firefox
> plans to deploy with it enabled for HTTP.
>
> On Wed, Mar 31, 2021, at 06:41, Matt J
Would it be possible to publish this document in a format that can be
opened by everyone without using proprietary software?
Thank you,
Marten
On Mon, Nov 30, 2020 at 10:40 PM Liaison Statement Management Tool <
stateme...@ietf.org> wrote:
> Title: LS on ATSSS Phase 2 conclusions
> Submission Da
How is this attack different from initiating a new TLS handshake, as the
server will also use secure random in that case?
On Thu, Oct 29, 2020 at 19:04 Florentin Rochet <
florentin.roc...@uclouvain.be> wrote:
> Dear QUIC designers,
>
> I've been recently following the discussion on PATH_CHALLENGE
To me, what matters more than people just interested in QUIC multipath, are
people who’re actually willing to put in the work to implement it,
experiment with it on an internet-wide scale and gather data to inform
future specification work.
Given the current status of most QUIC implementations, I'
One of the pillars of standardization work at the IETF is running code.
Aside from some proof-of-concept implementations of multipath, I'm not
aware of any implementation supporting any kind of MPQUIC, let alone any
internet-wide experiments / deployments. From what I've seen on the interop
runner,
50 matches
Mail list logo
