Re: Renumbering ... Should we consider an association that spans transpo

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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf