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