Draft: draft-ietf-quic-transport

Commentary: with the aim of being editorial . Assuming one used the only sensible interpretation of the parameter definition , there should n't be an code change except renaming the parameter in logs and stats . Also took recommendation to avoid the overloaded word " datagram . " 
 Well that was a very annoying merge conflict . Sorry for the noise . 
 I realize QUIC is fairly tied to UDP , notably in all transport text . But if you want to modify QUIC to run over a separate channel like over a bluetooth bus , would you then invent a new transport parameter for that , or would packet size be the right choice ? If so , renaming to UDP might have some consequences . 
 Note that the name of the document is " QUIC : A UDP - Based Multiplexed and Secure Transport " . 
 Editors , I believe the latest commit covers all open concerns about the PR . 
 At the moment , the maxpacketsize Transport Parameter is a size limit of " a packet , " and we seem to interpret it as " a QUIC packet . " I am not sure if that has been our intent . IIUC , the reason we have this TP is to tell the peer the maximum size of a " UDP datagram " that the endpoint can handle . Not the maximum size of a " QUIC packet . " The problem with having this limit being defined at QUIC packet - level is that it allows the sender to send a coalesced packet that consists of multiple QUIC packets , each of them consuming maxpacketsize bytes . For example , when responding to a client - sent Initial , a server is allowed to send a coalesced packet containing one Initial , one Handshake , one 1 - RTT packet , each of them in full size , and expect the client to not drop the coalesced packet , assuming that the network can handle jumbo packets < sup1</sup . This means that a QUIC stack needs to be prepared of handling UDP datagrams at most bytes . I do not think we would want to do that . Therefore , the proposal is to change the definition of the TP from maxpacketsize to maxdatagramsize . As an alternative , we can change it to maxippacketsize , but considering the BSD socket API , I think that maxdatagram_size would be a more natural fit . [ 1 ] Note that there is a performance incentive to configure QUIC endpoints to send jumbo packets . 
 This seems like a reasonable change to me . I assume this requires changing some of the surrounding text , not just the TP name , which would make it a design change I believe ? 
 I agree . This seems like a good change , though I had already interpreted this value as "  UDP payload size " in the msquic code . I went back and looked at the text , and it 's not 100 % clear whether it was supposed to be for a QUIC packet or UDP datagram . It does say ' packet " , not " datagram " , but that word has been used interchangeably in the past ... You might argue that it was always supposed to be UDP datagram payload length and call this editorial to clarify that , but calling it design is probably best . 
 I agree that clarifying this would be helpful . However , I think the term " datagram " is already very overloaded ( for example we have a ) , how about something very explicit such as ? 
 I like this change too . My understanding is TP maxpacketsize is  payload size the receiver can accept , and maxdatagramsize is a congestion control parameter for the sender ( need to be found by PMTU discovery ) . To avoid confusion it 's better to have a consistent name . 
 I like the change , but would strongly encourage us to just make it editorial . This is a very clear case of " we know what we meant . " 
 want to write a PR and that should clarify whether it 's editorial or not ? 
 To highlight  's point , the DATAGRAM draft has s TP named - these two in coexistence would be unfortunate . 
 This was never intended to be a limit on datagram size . That is , it was intended to be a limit on the length of ciphertext passed to the AEAD . That said , this is probably the right approach . The size of the buffers you need to catch a UDP packet are probably more relevant than the size of the AEAD inputs . I do note , however , that the construction of the Retry packet is such that the inputs to the AEAD might be greater in length than the packet itself . And Retry has to be sent without even looking at the client 's limits . Maybe we need to say that Retry needs to be no more than 1179 bytes in length ( to allow for the largest possible connection ID to be ) . That should n't be a problem in practice , as there is strong motivation for the Retry token to be much shorter than that - to the point that an 1179 - byte Retry probably will have a token that does n't allow for any data in an Initial packet - but we should be clearer about our limits . Please do n't claim that this is an editorial change . It is not . 
 If we are to impose a limit on the maximum size of Retry packets , I think a value much smaller than 1179 should be chosen . This is because a Retry token that is as large as that would leave almost no space for payload in Initial packet sent in response to the Retry packet . PS . Or to paraphrase , I think we can assume that clients would have a smaller limit than 1179 for the size of Retry tokens ( and therefore for Retry packets ) . I agree that clarifying that might be helpful . 
 I always assumed this was the equivalent of the TCP MSS option , rather than something to do with AEAD . Even if we decide to do nothing else , we should probably add some more text about what this is communicating and how to set it . But now the last sentence about unprotected packets make sense , so thanks for the insight . But it seems we 're converging on a TCP MSS - like purpose instead . 
 FWIW , I had assumed it was UDP payload size , since I need to ensure receive buffers are large enough . 
 I really do n't think we should place a limit on retry token size . This is very much a case of Also , I do n't see as a real world problem , and we should n't engineer around this theoretical . I would very much be in favor of making this and making it apply to all packet types . 
 Could we possibly use the term segment as in maxsegmentsize to refer to the UDP payload size including aggregated packets in one payload ? Using such a term is transport media neutral and would work over non - UDP media as well . 
 As others have noted , this can be a UDP - specific value . If we start to push this over different substrates ( ATM anyone ? ) then a different transport parameter might be better . Making this UDP - specific means that we can apply clean constraints on the value . 
 I 'm OK with that . 
 In , we discussed remembering transport parameters . The spec currently implicitly requires that be remembered . However , it does not explicitly prohibit servers from accepting 0 - RTT when it plans to reduce the value of this transport parameter . That might lead to clients sending 0 - RTT packets that are too big for the server . I see two options : that the server not accept 0 - RTT if it plans to reduce this value . that the client use the minimum value ( 1200 ) for 0 - RTT . 
 I will note that we already had this discussion in ( and it was the two of us ! ) What are the use cases where maxpacketsize would change ? the server interface has changed and ca n't accept these anymore -- I would think this was de facto going to result in not accepting  if the packets were too large . I 'm not sure why we would reject  packets that happened to fall under the new limit , in this case . the maxpacketsize is being set for some other reason -- perhaps to match an MTU on the other side of a proxy , to reduce copying . Again , as a proxy implementer I 'd probably take the data but dictate that future packets be correctly sized . Is there some other use case I 'm not aware of ? 
 I do not like the idea of option 2 . I think 1 is likely ok , though if the server can process the 0 - RTT packets , it 's just sub - optimal performance - wise(as in second example ) then it 's a bit annoying to have to choose between not decreasing the MTU and rejecting 0 - RTT . 
 I think we need to see more ( supportive ) discussion in order to justify taking this on . 
 I would like someone to articulate what harm is done if the server were to accept 0 - RTT when the maxpacketsize has decreased . 
 Consider the case where the original value of maxpacketsize was 9000 , and client sending 0 - RTT packets of 9000 bytes . If the server 's maxpacketsize goes down to 1280 and the server accepts 0 - RTT , the client would consider the 0 - RTT packets it has sent to be lost . I think that would halve CWND ( to 5 MTU ) and we 'd exit slow start . This negative impact is likely to be greater than the benefit we 'd get from 0 - RTT . That said , I am not sure if I like the framing of the discussion , or the current definition of . I think we might be conflating the maximum size of QUIC packets and the maximum size of UDP datagrams , and I might argue that what matters in reality is the size of UDP datagrams . As is a limit at the QUIC packet level , the transport draft allows a sender to send ( and therefore requires a receiver to not discard ) a UDP datagram that contains multiple QUIC packets being colesced , each of those QUIC packets being as large as . A server might send a UDP datagram that is 3x of ( datagram consisting of full - sized Initial , Handshake , 1 - RTT packet ) . Once a client receives the TP , it might send a UDP datagram that is 2x of ( consisting of full - sized Handshake and 1 - RTT packet ) . Are we fine with that ? Should n't we better change the TP to ? 
 I 've opened to discuss the issue described in my comment right above . 
 Regarding the original issue , I think I prefer something different than the two options being suggested . not require any behavior on the client - side . Allow servers process packets ( or datagrams ) larger than the advertised limit . As stated in my previous comment , there is a risk of seeing inferior performance when the client uses a large packet size that was advertised by the previous connection which is greater than the new maxpacketsize , and if the server accepts 0 - RTT . But the fact is that by sending a packet that is larger than 1200 bytes , the client is already taking the risk that 0 - RTT packets might get dropped ( by the network ) . Also , I do not see why endpoints have to be required to drop packets ( or datagrams ) that is greater than the advertised value . I think we can simply say that maxpacketsize ( or maxdatagramsize ) is an advisory value , much like maxidletimeout . 
 I like suggestion , and I especially agree with the point about already risking the network dropping the packet if it 's more than 1200 bytes . There 's no need to say you must drop the packet if it 's bigger . If you ended up being able to receive the packet successfully even though it was more than you advertised , go ahead and process it . 
 I suppose the only normative change from the existing text would be that clients MAY forget the value from previous connections when sending  . While I do n't have a strong opinion on this , I think I 'd prefer to just close this with no action , or at most an editorial change , thus forcing clients to remember the value . Freeing the client is not a lot of value add for protocol churn at this stage . 
 I think the counter argument would be that it does not cause churn , because clients that are willing to remember the value can . Also , assuming that we agree that " maxpacketsize " was in fact " maxudppayloadsize " ( as we 've been discussing in ) , I 'd point out that applying the " maxudppayloadsize " of the previous connection is going to be pretty complex . A client should not be sending a coalesced datagram that is greater than " maxudppayload_size " until it learns that peer 's maximum for the current connection . Therefore , a client would be having different limits on the packet size depending of if it is generating a coalesced packet . I am not sure if we should design our protocol based on such a complex ( and IMO fragile ) design . 
 I do n't like proposed change . The point of this is to express a limitation of the endpoint . If the endpoint only has X bytes of memory for receiving packets , then it can use this limit . Absent this , we ca n't ever hope to have big endpoints talking to little ones . We will end up with middleboxes ( hello CoAP ) . If the limit exists at a server and the client ignores it for 0 - RTT , then the effect is that 0 - RTT does n't get through . I would rather just say that client 's are expected to remember it and then if they do n't they can wear the consequences . But that can be a protocol violation . The problem here is that we now have protection for Initial packets and no way to signal that there is a limit . Our only real protection there is that the limit manifests in much the same way as having a lower MTU because Initial packets do n't get through . This matters especially if clients start remembering or inferring path MTU . I do n't remember us ever expressly allowing this sort of thing , but it seems like a reasonable thing that might happen when probing can be quite costly and wasteful . 
 Yes , I share the view that the sender should adhere to the receiver 's advertised limit . But that does not mean that exceeding the limit needs to trigger a protocol violation , or if the receiver should be allowed to trigger that . I might argue that , in practice , receivers would not trigger protocol violation when it receives a QUIC packet that is larger than the advertised maximum . This is because the receiver has to decrypt the packet that is larger than its limit in order to check that the packet was not spoofed . But is there an incentive to have a buffer that is larger than the advertised maximum just for this purpose ? I do not think so . I 'd assume that endpoints would simply advertise its buffer size . I think we just have different view points . One way of viewing this TP is that it is an ordinary TP , and therefore that when 0 - RTT is being used , the resumed connection inherits this TP too from the previous connection . The other way of viewing this TP is that it is an optimization of PMTUD , that lets a receiver advertise the maximum size of a datagram that is capable of processing . PMTUD needs to be applied per each connection ( or to be precise per each path ) , regardless of if 0 - RTT is used . If we view the TP this way , it can be considered something that kicks in when the TP is received for every connection . IMO the latter view is simpler in terms of implementation complexity , and has no downsides . 
 This is probably right . The effect of exceeding this limit is most likely that the packet will be dropped . So it looks like an MTU limitation that exists regardless of the path . Encouraging clients to remember this is still the right thing to do though . The alternative is terrible performance , as only some 0 - RTT packets - the small ones - end up getting through . 
  , I believe that this should be design .  and I might disagree about the relative value of requiring this change , but it is design even if we do nothing . It 's minor : we already strongly recommend remembering the parameter , we just do n't mandate rejection of 0 - RTT if the value is reduced . That is what the PR does .  has promised to talk to Kazuho and determine what to do next . I will defer to  's judgment here . 
 After chatting with and  , I recommend that we not make any change . With the current spec , where a server is not required to reject  , it means that the server might reduce this value and a client might have to cope with the network ( or server ) dropping larger  packets , which it would misconstrue as congestion . OTOH , if the server receives these larger packets despite it having reduced its maxudppayloadsize , it seems a waste to drop packets that have reached and can be processed by the server . Subsequent client connections should use the revised value anyway since the server will communicate a new value in the ServerHello . ( FWIW , a client could _ use a new reduced transport parameter from the server as an indication that any  losses were probably not due to congestion . Granted this is a bit of gymnastics , but if a client were to care about the performance of this rare case , it is possible for it to reasonably revert any congestion control action . ) My opinion is n't super strong , but this issue is minor enough . Let 's move along to more important things . 
 It looks like consensus is to close this with no action . If so , I believe this can be marked has - proposal ? 
 I want to add to this . Looks good , thanks !
Paragraph (version A):
During connection establishment, both endpoints make authenticated
declarations of their transport parameters.  These declarations are
made unilaterally by each endpoint.  Endpoints are required to comply
with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling.
Paragraph (version B):
Transport parameters are declarations that are made unilaterally by
each endpoint.  Each endpoint can choose values for transport
parameters independent of the values chosen by its peer.
Paragraph (version B):
A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an observer to the connection on which
it was issued, unless the values are encrypted.  For example, it
cannot include the previous connection ID or addressing information.
A server MUST ensure that every NEW_TOKEN frame it sends is unique
across all clients, with the exception of those sent to repair losses
of previously sent NEW_TOKEN frames.  Information that allows the
server to distinguish between tokens from Retry and NEW_TOKEN MAY be
accessible to entities other than the server.
Paragraph (version A):
The maximum packet size parameter is an integer value that limits
the size of packets that the endpoint is willing to receive.  This
indicates that packets larger than this limit will be dropped.
The default for this parameter is the maximum permitted UDP
payload of 65527.  Values below 1200 are invalid.  This limit only
applies to protected packets (packet-protected).
Paragraph (version B):
The maximum UDP payload size parameter is an integer value that
limits the size of UDP payloads that the endpoint is willing to
receive.  UDP packets with payloads larger than this limit are not
likely to be processed by the receiver.
Paragraph (version B):
The default for this parameter is the maximum permitted UDP
payload of 65527.  Values below 1200 are invalid.