Hi Christian, I think host identity together with a generic session identification mechanism would make it easier to promote the decoupling, there would be more good reasons to upgrade the stack - e.g. server load balancing and troubleshooting in the "middleboxed" Internet would be a lot more easier to carry out.
HTTP deploys cookies to identify sessions and a Server Load Balancer uses the cookies to do load balancing, especially if the clients are behind a NAT device. Using cookies as the session identifier is the only mechanism to ensure that the client is communicating to the correct real server, also to achieve good load balancing if there are many clients behind one NAT device. Also SIP people are building their own mechanism to identify sessions http://tools.ietf.org/html/draft-kaplan-sip-session-id-02 1.2. The use-case for Session-ID The need for a unique identifier is driven by the need to troubleshoot SIP sessions as they cross SIP nodes. Troubleshooting is more complicated if multiple legs of the session are on different sides of B2BUA's, due to the lack of a common identifier to tie the legs together. Currently proprietary mechanisms are used to achieve this. It seems that application people are already developing their own specific solutions to have an end-to-end session identifier mechanism. HTTP uses cookies, SIP is developing their own mechanism and perhaps there are more applications having similar solutions developed or under construction - could this get out of control, if every application develops their own method to identify an end-to-end host/session??? It would be great if the transport layer (or something between the transport and network layer) have a standardized host identifier (not relying on the network locators) with a session identifier that all applications could access - if the application developers find it useful. And the middleboxes should not be allowed to touch the host/session identifier - the main purpose of the identifier is to provide a troubleshooting tool that provides visibility behind NAT/middleboxes, a mobility enabler (with a session identifier you might restart a TCP connection, security issues arises and now I'm on thin ice) and a new routing architecture enabler. A host/session identifier could be e.g. the following: the host part derived from the MAC address from one attached NIC and the session identifier could be just a random counter that changes every time the application layer initiates a new session. So one part is globally unique and the other part is session unique - just as an example. Ports are used to identify services and I don't see a reason to change that mechanism.....or?? -- patte On Tue, Jun 30, 2009 at 11:14 PM, Christian Vogt<[email protected]> wrote: > Hi Patte - > > You are absolutely right that decoupling services and sessions from > their location would be highly useful. The current conflation of > identification and location certainly has serious disadvantages. For > example, decoupling would mitigate the routing scalability problem. > > But are you saying that using a host identity as part of service or > session identification is necessary to achieve this decoupling? > > - Christian > > > > On Jun 30, 2009, at Patrick Frejborg wrote: > >> Hi Christian, >> >> I think service identification and session identification is belonging >> to the transport layer in the IP reference model - in the OS model >> they are on separate layers. So in the IP model I would collapse them >> under one identifier, I think that is what we have today. E.g a TCP >> connection is identified by the five tuples; source and destination >> addresses, source and destination ports and protocol. But here the >> problems starts, a connection/session/association is identified by >> elements from the network layer (source and destination addresses) - >> thus the border between the network and transport layer gets very >> blurred. I believe that this is the reason why we today need to have >> global unique IP addresses, with global addresses we can identify >> connections on hosts, security and NAT nodes - it is the only method >> at the moment, right? >> >> Adding a host identifier to the IP reference model wouldn't add much >> value - unless it can decouple the dependency between network and >> transport layer. If the host identifier could give an identity for a >> connection without deep dependency to the network layer an new world >> opens. I.e. a connection could be identified by some other mechanisms >> than the network tuples. Then we could migrate from a single-level >> address scheme to a multilevel address scheme and create a better >> routing architecture without the need to have global unique addresses. >> And mobility would be much easier to achieve, i.e. if connections are >> identified by something else it doesn't matter when the underlying >> network changes - the application will not be aware and doesn't care >> about the network parameters. >> >> SCTP goes in this direction but the current mainstream transport >> protocol is TCP. Guess people will not move their applications to use >> SCTP instead of TCP in order to improve the routing architecture of >> Internet, right? >> I think the only way is to fool TCP that underlying network is still >> the same though it isn't - something is needed between the network and >> transport layer that the applications aren't aware of. By having a new >> layer we could change the underlying addressing scheme with backwards >> compatibly to the current addressing scheme - not all stacks needs to >> be upgraded since it is backwards compatible. This will not improve >> mobility but mobility will be improved once people are starting to >> move their applications to use the host identifier to identify >> connections on the transport layer. Would people move their >> applications to support mobility? I think it is matter of time, there >> are so much mobile devices connected to Internet that enterprises will >> see business opportunities to move applications to an infrastructure >> that better supports mobility, this is long term vision but guess it >> will happen. >> >> So I think the identifier(s) should be designed to decouple the >> transport layer from the network layer. Opponents will say that all >> hosts must be upgraded, this is not true if the the new stack is made >> backwards compatible with fallback mechanisms to the current >> architecture. >> >> >> -- patte > > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
