On Tue, Dec 30, 2025 at 2:10 AM Aijun Wang <[email protected]> wrote:
> Hi, Eric: > > > > Contrary to your conclusions, I think the application layer and TLS/TCP > layer should(already) have their own mechanisms to assure the data > integrity, > Yes, which might or might not work correctly, because they are rarely tested. > there is no necessary to consider them again at the protocol layer, we > need just some guidance for the implementation of client/server sides > themselves. > > If there is data arrival during the switchover, the internal > implementation logic is the application layer will call the api of TLS/TCP > to send some data, with the same session identifier. > I don't know what you mean by "The same session identifier". There is no concept in TLS that two different TCP connections are somehow the same conceptual flow of data. PSK identifiers solely identify keys. > In this case, the client doesn't know what has happened. You need > mechanisms either at the HTTP layer--or more typically at the REST API > layer--to do the right thing, which might be an idempotency layer > combined with client-side retransmit. This is all just a > straightforward application of the end-to-end argument, and there's no > real way around it as long as systems might asynchronously fail, but > it's also a source of defects (think about how many times sites tell > you not to press the submit button twice) because these mechanisms may > not have been exercised or tested. For instance, if the server is high > reliability and the client just assumes that anything it sent works, > that will be good enough a very large fraction of the time, but not if > the server has a high failure rate. > > > [WAJ] From the example, we can know each application has its own > confirmation mechanism, because most of them are asynchronous. > > The application knows there will be possibilities that the server crash, > or the underlay connection broken. > Yes. I said exactly this, but again, they're not always going to be implemented correctly, and that's largely OK because most connections don't fail. You're talking about making an exceptional condition routine. Unfortunately, these transaction semantics only exist at the HTTP > layer, not the TLS layer, so the TLS layer has no way of knowing to > wait for the 200 OK, it just knows that the client sent some data, but > not whether that reflects an outstanding request or something else; > recall that TLS doesn't even know about the HTTP request/response > semantics, because it's just a dumb pipe. > > [WAJ] TLS needn’t aware the 200 OK signal, it is the job of application > layer. > > TLS/TCP needs only transmit the data from the application layer correctly > to other side. > So you're saying that in the example above, the TLS layer ought to inform the HTTP layer that the connection has failed and trust the HTTP layer to retry in a safe fashion? > In your email, you suggest that the client ought to: > > 1. Wait for the server's TCP ACK of all transmitted data, with the > implied semantics being that once the message is ACKed it will be > reliably delivered to the server, not just to the TCP stack. > > [WAJ] No. I emphasize only the TCP ACK and the TCP stack. Not the > application stack. That is to say, receiving the TCP ACK doesn’t represent > the application layer ACK. > > > 2. Buffer any data it receives form the cleint while waiting for the > ACK and retransmit it on the new connections. > > [WAJ] Buffer any data it receives, but can’t transmit immediately during > the switchover process, not waiting for the application ACK. > I don't understand what you're saying here. Can you please provide: 1. A concrete description of what you believe the rules that the TLS stack should be following. 2. New versions of my ladder diagrams that show what you believe the correct behavior is. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
