Re: [tae] [tsv-area] Transport negotiation

[james woodyatt <[e-mail]>]

On Dec 9, 2008, at 16:34, Joe Touch wrote:
>
> That's one perspective; I have another, e.g.:
> http://www.isi.edu/rna/
>
> This is somewhat similar to John Day's view on layering.
> [...]
> All layers are capable of:
> 	state coordination (soft, hard, etc.)
> 	flow control
> 	error recovery
> 	order restoration
> 	multiplexing/demultiplexing
> 	framing
> 	security
> 	etc.
>
> What distinguishes layers, IMO, is scope and the relation to the
> services it requires a-priori. I don't consider the above the unique
> purvue of the transport layer, to be sure.


 From where I stand, i.e. smack in the middle of your transport-aware  
packet-forwarding plane-- where, as Stuart so kindly reminded us in a  
previous message, I am using the word "transport" to talk about my  
naïve and misguided notions concerning what identifies the layer above  
the one currently subject to forwarding-- the upper layers look  
altogether like a stack of transports with the one at the top being  
designated an application by virtue of the magical fact that it isn't  
being used to transport anything else, and the one at the bottom  
being-- hopefully-- the *only* one the transport-aware forwarding  
plane has to care about (but, of course, hopes are always dashed on  
the Rock Of Exceptions).

It so happens that I would dearly love to see the Internet packet- 
forwarding planes simplified to make them not have to care *at* *all*  
about what I'm calling "transports" here, but it seems like every time  
I've tried to help that along, I've ended up getting punched in the  
neck by reality.  So, I'm pretty well sold on the RNA idea: if you ask  
me, we may as well regard the architecture as "transports" from top to  
bottom, from XML schema all the way down to the 802.11 PHY layer.  I'm  
totally game for this.

Looking at Bryan Ford's "Breaking Up The Transport Logjam" paper, I  
can imagine defining an Endpoint Identity extension header that  
comprises the source and destination service identifiers, independent  
of what we might traditionally regard as the transport layer, for any  
given IP packet.  I can also imagine defining separate flow and  
ordering control, rate control, congestion avoidance, and connection  
maintenance extension headers, all of which are independent of the  
transport layer.  There might not be anything left of the traditional  
"transport" layer when we get done, but I suppose that could be  
regarded as a feature: the objective being to split the existing  
transport layers up into a toolkit of combinatory extension headers.

But is it a good idea to do it this way?  It doesn't seem likely when  
I think about it.  Why not just define a single layer that unifies all  
the various E2E tools in one conceptual model?  (I'm now remembering  
an esoteric transport protocol called XTP that purported to attempt  
this.  <sardonic>I wonder whatever happened to it.</sardonic>)

I think I must be missing something important about this transport  
logjam problem or making some unwarranted assumptions related to it.   
Hopefully, the others here will set me straight.  I'm looking forward  
to it.


--
james woodyatt <[e-mail]>
member of technical staff, communications engineering


_______________________________________________
tae mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tae