Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-17, at 17:40, ext John Day wrote: Fast Select was a single packet that opened, transfered data, and closed a connection. The same as what Mr. Ford's description. What you outline above is very different from SST. I'm surprised that after reading the paper you'd think that there are strong similarities. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-14, at 21:54, ext Tony Finch wrote: On Fri, 14 Sep 2007, Keith Moore wrote: I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? I agree, except that pretty well is a bit crappy when every connection has to re-establish authentication and encryption - which is what drives some protocols to implement their own multiplexing. mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. I agree, especially because some software has problems telling the difference between clean and dirty closes. However there's a latency / efficiency trade-off, and TCP pushes you towards pipelining multiple transactions down a few connections even when a more natural design might have greater concurrency. mumble. You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html Abstract: Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for long-running conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3- way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head- of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic “large datagram” problem, where a datagram's loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10% of kernel TCP on a WiFi network. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Dumb question of the month. With the exception of the last claim (...can prioritize...), this could just as easily describe SCTP. What here is new? And define prioritize? On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote: You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html Abstract: Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for long-running conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3-way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head-of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic “large datagram” problem, where a datagram's loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10% of kernel TCP on a WiFi network. Lars___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-17, at 12:13, ext Fred Baker wrote: Dumb question of the month. With the exception of the last claim (...can prioritize...), this could just as easily describe SCTP. What here is new? And define prioritize? For how this relates to SCTP, let me refer you to Section 6. (And yes, there are obvious similarities here to SCTP, but also RFC2140- like integrated congestion control, etc.) Prioritize meaning how a sender allocates the available path capacity for the SST bundle between connection instances. A demo that Bryan did that showed HTTP over SST dynamically adjusted priorities such that objects that were being rendered on the screen were transmitted at a higher priority, even while scrolling around a large page. On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote: You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Hi Lars, comment in-line. Best regards Michael On Sep 17, 2007, at 12:11 PM, Lars Eggert wrote: On 2007-9-17, at 12:13, ext Fred Baker wrote: Dumb question of the month. With the exception of the last claim (...can prioritize...), this could just as easily describe SCTP. What here is new? And define prioritize? For how this relates to SCTP, let me refer you to Section 6. (And yes, there are obvious similarities here to SCTP, but also RFC2140- like integrated congestion control, etc.) Prioritize meaning how a sender allocates the available path capacity for the SST bundle between connection instances. A demo that Bryan did that showed HTTP over SST dynamically adjusted priorities such that objects that were being rendered on the screen were transmitted at a higher priority, even while scrolling around a large page. The SCTP sender can handle multiple messages in different stream send queues in different ways. I call the selection function the stream scheduling function. Using different scheduling functions at the sender side you can get different fairness concepts. Message based round robin would get the fairness concept of having the same number of messages in each stream, doing a weighted fair queueing based scheduler you can share the bandwidth equally between the different streams and so on. Priorities are also simple to implement and have an analysed in http://www.cis.udel.edu/~amer/PEL/poc/pdf/sci2004-heinz-SCTP- Prioritized-Multistreaming.pdf The nice thing with the scheduling function is: it is a sender only thing. The receiver has to follow some simple rules, which almost all SCTP implementation do anyway. On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote: You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
I am afraid that I must agree with Fred. There is nothing very new in this paper and its publication is merely another indication of how far down the blind alley we have gone. I was surprised SIGCOMM even published dressing up X.25 Fast Select with fancy words. Amazing. At 2:13 -0700 2007/09/17, Fred Baker wrote: Dumb question of the month. With the exception of the last claim (...can prioritize...), this could just as easily describe SCTP. What here is new? And define prioritize? On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote: You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http://www.brynosaurus.com/pub/net/sst-abs.html Abstract: Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for long-running conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3-way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head-of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic large datagram problem, where a datagram's loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10% of kernel TCP on a WiFi network. Lars___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On Mon, 17 Sep 2007, John Day wrote: I am afraid that I must agree with Fred. There is nothing very new in this paper and its publication is merely another indication of how far down the blind alley we have gone. I was surprised SIGCOMM even published dressing up X.25 Fast Select with fancy words. Amazing. Isn't Fast Select more like RFC 1644 TCP for Transactions than Ford's Structured Streams? IIUC, X.25 and SCTP have similarly static multiplexing configurations and delimited records, unlike SST. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Fast Select was a single packet that opened, transfered data, and closed a connection. The same as what Mr. Ford's description. There was nothing remotely transactional about Fast Select. It was a direct counter to the proposal to put datagrams in X.25. It was a silly idea, then and it remains so. Deeper thinking about the nature of the problem would have yielded simpler results than SST. I do admit to taking a cheap shot at one of the more obvious weirdnesses in an amazingly weird paper as SIGCOMM continues to promulgate the groupthink, rather than break it. At 15:07 +0100 2007/09/17, Tony Finch wrote: On Mon, 17 Sep 2007, John Day wrote: I am afraid that I must agree with Fred. There is nothing very new in this paper and its publication is merely another indication of how far down the blind alley we have gone. I was surprised SIGCOMM even published dressing up X.25 Fast Select with fancy words. Amazing. Isn't Fast Select more like RFC 1644 TCP for Transactions than Ford's Structured Streams? IIUC, X.25 and SCTP have similarly static multiplexing configurations and delimited records, unlike SST. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Thu, 13 Sep 2007, Keith Moore wrote: Offhand I don't know why it should be necessary to build a mechanism that spans several transport lifetimes. TLS session caches. HTTP cookies. FTP control connections. Apps that want to deal with concurrent data streams within one user's session currently have to establish and authenticate multiple TCP connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and windowing at the application level (e.g. BEEP, ssh). A session layer would allow an app to establish a security context once then re-use it when establishing new transport connections, so that re-connecting can be cheap and concurrent data streams can be simple. Unfortunately TCP doesn't share congestion information between connections, which penalises new bulk-data streams and requires workarounds at the application level (e.g. HTTP/1.1 persistent connections). (I have been thinking along similar lines to Karl.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Tony Finch wrote: On Thu, 13 Sep 2007, Keith Moore wrote: Offhand I don't know why it should be necessary to build a mechanism that spans several transport lifetimes. TLS session caches. HTTP cookies. FTP control connections. okay fine (at least for the first two) but should that information be managed by the application, or at a lower layer? particularly if it needs to be shared among multiple instances of a service that may reside on different hosts? Apps that want to deal with concurrent data streams within one user's session currently have to establish and authenticate multiple TCP connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and windowing at the application level (e.g. BEEP, ssh). I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? A session layer would allow an app to establish a security context once then re-use it when establishing new transport connections, so that re-connecting can be cheap and concurrent data streams can be simple. Unfortunately TCP doesn't share congestion information between connections, which penalises new bulk-data streams and requires workarounds at the application level (e.g. HTTP/1.1 persistent connections). mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On Fri, 14 Sep 2007, Keith Moore wrote: I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? I agree, except that pretty well is a bit crappy when every connection has to re-establish authentication and encryption - which is what drives some protocols to implement their own multiplexing. mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. I agree, especially because some software has problems telling the difference between clean and dirty closes. However there's a latency / efficiency trade-off, and TCP pushes you towards pipelining multiple transactions down a few connections even when a more natural design might have greater concurrency. mumble. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? ... If you had a separation between locator and identifier, the application could bind to the identifier and renumbering events could occur on the locators without impacting the identifier. For a long time I've suggested that we begin to look anew at the idea of an association as an abstraction over transport. Yes, I know that this smacks if ISO/OSI, but there were a few granules of good ideas there. The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Then, if the underlying transport goes away, perhaps due to movement in a mobile network or renumbering, then the association is reconstructed on a new transport that is built in accord with the current addressing and routing conditions. Reconstruction does not, as some have assumed, require that the network remember anything or hold any state. Rather, taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. Basically whenever applications establish a transport they say Ahem, where were we when we last spoke. One answer is We did not last speak Another answer is we last agreed on the checkpoint named 'foo'. How they recover from 'foo' is entirely application dependent. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) (I'm also thinking of TCP based applications, not UDP based ones. For them I don't see renumbering as much of a problem, but I may not be seeing enough.) This is not something that can readily be transparently back-ported into existing protocols; it's not something of trivial import. But it can be deployed for new applications and not invalidate either existing applications or existing application protocols. And consider, for example, how something like this might have obviated the need for the IP layer triangulation in mobile IP. --karl-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Offhand I don't know why it should be necessary to build a mechanism that spans several transport lifetimes. I would much prefer that we re-engineer our transport protocols to let them work in terms of endpoint IDs. In particular, checkpoints would seem to make life more complicated for applications by lowering the level of service from transport protocols - because I think it would be hard to implement transport-independent and application-independent checkpointing in a way that made sense. I do however think that there might be a place for a mini layer in between IP and transport that accomplished a few things that we seem to need in all transports. e.g. management of ID-LOC mapping, management of multiple LOCs per endpoint ID, striping of traffic across multiple paths, management of RTT and other estimators, congestion control, peer authentication, encryption, and explicit interaction with layer 3 intermediaries. Keith For a long time I've suggested that we begin to look anew at the idea of an association as an abstraction over transport. Yes, I know that this smacks if ISO/OSI, but there were a few granules of good ideas there. The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Then, if the underlying transport goes away, perhaps due to movement in a mobile network or renumbering, then the association is reconstructed on a new transport that is built in accord with the current addressing and routing conditions. Reconstruction does not, as some have assumed, require that the network remember anything or hold any state. Rather, taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. Basically whenever applications establish a transport they say Ahem, where were we when we last spoke. One answer is We did not last speak Another answer is we last agreed on the checkpoint named 'foo'. How they recover from 'foo' is entirely application dependent. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) (I'm also thinking of TCP based applications, not UDP based ones. For them I don't see renumbering as much of a problem, but I may not be seeing enough.) This is not something that can readily be transparently back-ported into existing protocols; it's not something of trivial import. But it can be deployed for new applications and not invalidate either existing applications or existing application protocols. And consider, for example, how something like this might have obviated the need for the IP layer triangulation in mobile IP. --karl-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Sep 13, 2007, at 23:00 , Karl Auerbach wrote: The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Wouldn't that be the OSI session layer (that IP doesn't have)? taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. We already do that today at the TCP layer. Rather than reinvent TCP in all individual applications (all those checkpoints will be great for performance!) it's much easier to hide changes in IP connectivity from TCP. We also pretty much have that today, in the form of shim6. Note thought that none of that solves renumbering, rather, it really needs better renumbering support to work well. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) Seperating location and identity requires some pretty hefty security, otherwise anyone can impersonate anyone. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Sep 13, 2007, at 2:34 PM, Iljitsch van Beijnum wrote: The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Wouldn't that be the OSI session layer (that IP doesn't have)? Not necessarily. A 'session' in the OSI verbiage (at least as far as I can understand it ;-), spans across individual transport connections. The de-facto session layer that we have today in IP is an ssh tunnel, with applications tunneled across it and some very poor security within that tunnel. A key question here is whether the 'association' is a single connection or not. While the association may span the change of underlying infrastructure, the real question is whether it presents a single concatenated transport abstraction or if it's multiple connections. I think we need the former. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Tony Li wrote: A key question here is whether the 'association' is a single connection or not. While the association may span the change of underlying infrastructure, the real question is whether it presents a single concatenated transport abstraction or if it's multiple connections. I think we need the former. Wow, I wasn't expecting so much feedback in so few minutes. My motivations were these: Although I'd as a writer of applications like to have a reliable, sequenced data stream to my peer application(s), I figured that to do that inside TCP would be to reinvent TCP. And since I don't believe many of us think TCP is broken, reinventing TCP would not be a good use of our efforts. So I figured, OK, how can we keep our investment in TCP and existing applications and provide a tool that could be of use to people figuring out new applications. Sort of the way that BEEP is. And having long ago stuck more than an arm into ISO/OSI, and after seeing Marshall Rose's implementations of ISO session over TCP, I realized that what the OSI people were trying to do at the session layer was something simple wrapped up in an amazing amount of complexity. All they were trying to do was give applications a way of putting stakes into the ground so that they could go back to an agreed upon status if something went wrong and give it another try. To my mind it would be very wrong to require that the network in some way preserve application data for re-presentation; first off that makes the network too complicated and second, as several have pointed out, how each application recovers varies from application to application. Keith is very right that we don't want the network (including most of the stack code in clients and servers) to do what an application should do for itself, particularly with regard to buffering of data. That's why, to my mind, the association mechanism should be limited to merely letting the applications agree on a name or number, nothing more, and leaving it to the applications to figure out what to do if they need to go back to that name/number. And Keith is right in that what I am suggesting would not be a mechanism that would be transparent to existing applications. I've wrestled with the idea of pushing all of this down into the transport layer and, yes it could be done. But I have doubts that given the size of the net that it would be broadly adopted or be deployable. So I mentally punted and said How about an optional layer above TCP that newly designed applications could use? As Iljitsch points out, the checkpoint mechanism could become a lot of overhead for not a lot of benefit - although I sense that the overhead of establishing a checkpoint would involve perhaps one-to-two packet exchange/round trip times and might be able to occur in parallel with ongoing data flow (remember I'm suggesting only the establishment of a name, not any buffering of data except in the applications themselves.) And a well designed application protocol should only use a the checkpoint mechanism when it really needs to. It would be silly, for example, to checkpoint a DNS-over-TCP connection, but it might make sense for some mobile database access application to do it after each database update. But, as Iljitsch also suggests, we can get a lot of this if applications simply close the TCP connection then re-open it. But isn't that really a somewhat similar to I've suggested in that it requires the applications to go back to some point in the past and resume? I know that I'm walking close to the edge of a cauldron of worms, but I've seen these ideas of some sort of persistent relationship between application layer entities pop up in many contexts, such as mobile IP, VoIP, HTTP cookies, etc, that it occurred to me that maybe it is something that needs some coherent, rather than ad hoc, consideration. --karl-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
