On Sun, Jul 02, 2017 at 02:00:51PM -0700, Eric Rescorla wrote: > On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > There can also be interactions with giving up on fragment transmissions > > (in order to limit memory usage). > > > > Suppose similar case as before, but 2:1 gets lost instead of disappearing, > > and is found after 2:5 is received by the client. > > > > The client will then generate second ACK, which ACKs 2:1. The server then > > receives the ACK and has no idea what the client is talking about, since > > server has dropped the state. But presumably fast-retransmits 2:4 and 2:5, > > now as 2:6 and 2:7 (3rd transmission for both). > > > > It's not clear to me it's useful for implementations to delete state in > this case.
As said, this would be to limit memory usage. I suppose real cheap implementation could check for the first missing fragment and retransmit from that point onwards, regardless if any subsequent fragment was ACKed. I suppose if one really wants to scrimp on state, one combine the fragments of small messages (basically, everything except Certificate) in fixed way (ClientHello, HelloRetryRequest and ServerHello likely fit into one fragment, EncryptedExtensions and CertificateRequest likely jointly fit into one record, the same for CertificateVerify and Finished). And then assign RSNs for retrasmissions with fixed base (which impiles that RSN sequence might have gaps). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
