Re: Renumbering ... Should we consider an association that spans transports?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]