RE: [arch-d] What Problems are We Solving for the InternetArchitecture

["Bound, Jim" <[e-mail]>]

whoops below not "DNS" but DNA (for groups working on handover issues).
/jim 

> -----Original Message-----
> From: Bound, Jim 
> Sent: Tuesday, February 28, 2006 11:27 PM
> To: 'Fred Baker'
> Cc: [e-mail]
> Subject: RE: [arch-d] What Problems are We Solving for the 
> InternetArchitecture
> 
> Responses in line.  This was really off the top of my head 
> for content (less than 2 minutes) main point is we need some 
> form of framework to identify and depict what problems we 
> want to solve as template.  
> 
> > -----Original Message-----
> > From: Fred Baker [mailto:[e-mail]] 
> > Sent: Tuesday, February 28, 2006 5:17 PM
> > To: Bound, Jim
> > Cc: [e-mail]
> > Subject: Re: [arch-d] What Problems are We Solving for the 
> > InternetArchitecture
> > 
> > On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote:
> > > I suggest we make a productive list of what problems need 
> solving  
> > > and then discuss and get input on the priority of those 
> > problems, a  
> > > list of high level views on solutions, the probability of  
> > > implementation, and how a transition would be developed 
> to take us  
> > > there. Also keep suggestions within the bounds of an SDO, 
> which is  
> > > what the IETF is and its charter, mission, and objective.
> > >
> > > Example:
> > >
> > > Problem: Transport Layer needs to provide in the market 
> > failover to  
> > > new IP address, but not tear down the IP session 
> association. TCP/ 
> > > UDP do not provide session layer failover to multiple IP  
> > > addresses.  SCTP does permit this behavior.  How do we deprecate  
> > > TCP/UDP so SCTP can become the dominant NGN for the Transport  
> > > Layer, is there anything the IETF can do? (Ignoring DCCP 
> for this  
> > > example).
> > 
> > This particular problem is IMHO not well stated. STCP is 
>                                                    SCTP :-)
> > designed for  
> > a different problem than TCP.
> 
> My practical day job experience with customers running SCTP 
> is not congruent with your input, but good discussion.  For 
> this problem statement the proposition is that tearing down 
> transport connections can be avoided with SCTP and not with 
> TCP to add to what I stated.
> 
> > It is designed basically to support  
> > transaction processing in what is sometimes called a TCP-friendly  
> > manner, where a transaction might be as short as a few 
> hundred bytes  
> > or as long as a few tens of thousands. TCP was designed as a class  
> > four transport supporting a single synchronized exchange, 
> and in its  
> > testing has historically been used where there is one thing that  
> > someone wants to do, such as move a file or support an echoplex  
> > exchange.
> 
> SCTP incorporated all of TCP at least in implementations I 
> have seen and test results from it just extends the 
> capability of the transport layer you reference.  
> 
> NB: Randy Stewart are you on this list ??????????  Ping Ping :--)
> 
> > 
> > I would argue that we want to see SCTP deployment, but the 
> matter of  
> > IP Address replacement can be handled either by deployment of SCTP  
> > for the single-serial-session purposes, or TCP could sprout the  
> > capability.
> 
> I cannot understand your point here, sorry.  This is not this 
> specific problem space presented.  The objective first is to 
> create implementation deployment model and verification that 
> we can move to independent IP associations under SCTP 
> association as first step. Add/Delete of additional addresses 
> is supported by SCTP.
> 
> > 
> > The architectural question is really, I think, to complete the  
> > separation between the internet and transport layers, so that a  
> > transport layer session is not tied to a single address pair. 
> 
> Agree.
> 
> > In TCP,  
> > we could simply copy the SCTP approach, which has the session 
> > tied to  
> > a single address pair at any given time, or we could have each TCP- 
> > speaker simply announce to the other the various addresses 
> it might  
> > use, and one the announcement has been reliably received, have it  
> > assume that segments might arrive from any of the peer's announced  
> > addresses to any one of this system's addresses, but using 
> the same  
> > port pair and other TCB state. In that case, the peer is able to  
> > spread his traffic on all address pairs if it suits him, or change  
> > them at a whim, because instead of the TCP session having one 
> > address/ 
> > port-pair tuple that identifies it, it has m*n identifiers 
> that are  
> > mutual aliases, all equally valid at any given time.
> 
> True, but I believe SCTP is already done and can be used and 
> adding this to TCP is not worth the engineering cost or 
> effort as I see it right now.
> 
> > 
> > > Priority Questions:
> > >
> > > - Important to SHIM6, HIP, and Mobile IP. Are these 
> priorities and  
> > > are they building shims around TCP/UDP.
> > 
> > Personally, I think each of these has its place operationally 
> > and yet  
> > is also something of a kluge and overkill. That, to me, is 
> > the single  
> > biggest reason that the marketplace hasn't necessarily 
> adopted them  
> > or is driving these solutions.
> 
> I agree except for Mobile IP that is happening now for both 
> IPv4 and IPv6.
> 
> > 
> > If TCP and SCTP can announce an alternate address like I described  
> > above, now add the concept that they could withdraw an announced  
> > address. Mobile handover just got fixed - at least the easy 
> case in  
> > which there is a multiple RTT overlap during which the moving  
> > endpoint can send a message that announces the new address and  
> > withdraws the old one. The problem is of course that the 
> datagram is  
> > unreliable; the moving endpoint would want to send it from 
> its "old"  
> > address, the one its peer knows, and at least on a retransmission  
> > would want to send it to each of the announced addresses of 
> > its peer.  
> 
> I am not concerned today with the handover I believe current 
> groups like DNS and mobopts have very good handle on this and 
> I am more concerened about routing optimizations when the 
> node/device/sensor arrives at new link and the management of 
> that process.  
> 
> But I agree a new transport model with single session 
> association would permit us to reevaluate handovers.
> 
> > That still doesn't address the case in which the "old" 
> > address simply  
> > stops working (the mobile device turns a corner and simultaneously  
> > loses the "old" and starts acquisition of the "new"). So there may  
> > also be a requirement for a way for an entirely new session 
> > from what  
> > would appear to be an unknown party to identify and authenticate  
> > itself, produce the TCP/SCTP state that it knows, and pick 
> up where  
> > it had previously left off. That would require some concept of a  
> > session identifier... See RFC 2103.
> 
> Yes or simply give up and rebind which is what will happen in 
> practice today.
> 
> > 
> > Say "Locator/Endpoint Identifier split" (RFC 1992)... but it goes  
> > beyond Nimrod routing; while the Locator is a network layer 
> address,  
> > the Endpoint Identifier is a session layer concept, and what we're  
> > really saying is that we need some form of session 
> management layer  
> > that lives *above* the transport. Note I didn't say "the 
> ISO Session  
> > Layer" - please God, no - but something that lives in about that  
> > place and securely manages sessions.
> 
> Agree and strongly agree with 'please God no OSI session et al'.
> 
> > 
> > By the way, if I wrote a I-D named "we actually need a session  
> > management layer", how would I identify it? Is that 
> draft-baker-arch- 
> > *-??.txt?
> 
> Question is still premature for my brain.
> 
> > 
> > > - Would this help with network location vs. 
> identification of node/ 
> > > device/sensor
> > 
> > I think so. That said, I'm not entirely convinced that the 
> Endpoint  
> > ID needs to be numeric.
> 
> Agree.
> 
> > The Nimrod architecture discusses a binary  
> > value (the EID) and an ASCII value (the Endpoint Label or 
> > EL). What I  
> > think is actually necessary is a globally unique thingamajig 
> > that can  
> > be used to identify the system one wants to talk with, and 
> it could  
> > be a network layer address (as in IP Mobility), an ASCII or 
> Unicode  
> > name, or something else. That value of it being "something 
> else" is  
> > that one avoids the overloadings implicit in re-using 
> something that  
> > was actually designed for something else. However, using a network  
> > layer address has the elegance of providing a defined way to 
> > find the  
> > thing, and using a DNS name has the elegance of already 
> having a way  
> > to look things up. If we do "something else", we have to add 
> > that new  
> > thing to the mechanisms by which we do things, and do so in an  
> > elegant way. That might be hard.
> 
> Very hard.
> 
> > 
> > > - Is there a security advantage to supporting as dominant SCTP  
> > > Transport Layer context.
> > 
> > I think that's the wrong question. SCTP and TCP (and UDP if you  
> > include the methods by which the relevant application uses it) are  
> > implementations of the transport concept, not "the transport".
> 
> Thought was if we can enhance the security of transport layer 
> as we have network layer with IPsec to the one session from 
> SCTP main association that provides another door for bad guys 
> to break through as the door for the network layer.  The 
> other transport associations under the main association can 
> reuse the security set up (most of the cost for performance) 
> and the keys etc etc.  Very rough idea but has had some brain 
> storm discussion within some security focused forums as a 
> note under needs for multilevel security.
> 
> > 
> > > - Does it work for both IPv4 and IPv6.
> > 
> > The guy Nimrod is named for is fairly disgusted with IPv6 
> because it  
> > didn't address this problem and in its addressing 
> > architecture didn't  
> > leave him room to do a next generation routing 
> architecture. If you  
> > really want to address it, I *think* it can be done without re- 
> > defining the IPv6 address, but be prepared for that question 
> > to come up.
> 
> Cannot comment on the past.
> 
> My view is the IP adddress should only be the locator and new 
> abstraction is required for identifier.  IP layer or IP 
> address is not the place to solve the problem is my view.
> 
> > 
> > > - What customers in the market would find this useful for 
> IETF to  
> > > work on this as SDO.
> > 
> > I have heard from various ISPs that they would like to see this  
> > addressed. Many of those ISPs also tell me that I can deploy any  
> > routing protocol I like as long as it is BGP. So take that with an  
> > appropriate dosage of salt. I have also heard from various 
> > enterprise  
> > customers that they have problems that this kind of thing 
> might be a  
> > solution to. I haven't heard them say that this is the 
> solution they  
> > are looking for, however; they usually come in with a 
> > marketing pitch  
> > from one competitor or another and ask us what we think 
> about it, as  
> > opposed to saying "what I would really like to do is solve <this>  
> > problem" or "I need a solution that looks kinda sorta like 
> <this>".  
> > So while this is IMHO a useful class of solution, I haven't got a  
> > trivially obvious way to tie it to a customer-felt problem. The  
> > latter really helps...
> 
> My customers are seeing/complaining about the identification 
> for many reasons Mobility, Net+RFIDs, and the Network 
> Providers for other reasons we have discussed previously. 
> Also there is the security benefit.
> 
> > 
> > > - What enhancements could be made to SCTP for QoS Statistics  
> > > Gathering, Security, etc.
> > 
> > I believe that you actually will benefit from putting those in  
> > separate architectural entities.
> 
> Could be but many upstart router vendors are figuring ways to 
> determine traffic QoS from stats and in some very elegant 
> ways I am sure your aware of and just thinking can we extend 
> SCTP for inter/intra routing communcations also that clients 
> could be enhanced to assist with QoS feedback.
> 
> > 
> > Let me give you an example. If you look at the TCP state 
> machine, a  
> > fair bit of it is there to support graceful close - the 
> concept that  
> > we would like to close the pipe, but not before making sure 
> that all  
> > traffic has made it through the pipe in both directions. There is  
> > complexity there, and a bug (the TIME_WAIT issue) that TCP  
> > implementations have to fix. The Xerox Sequenced Packet 
> Protocol is  
> > much simpler, and relegates graceful close to the higher 
> layer, but  
> > provides a standard mechanism to accomplish it. Basically, 
> each peer  
> > tells the other using a tag that it has sent its last packet, and  
> > acknowledges receipt of that tag with another tagged 
> message. When a  
> > peer has announced to its peer that it is done and the peer has  
> > acknowledged that, and it has received the "FIN" tag from the peer  
> > and sent its acknowledge, it sets a timer, and when the timer 
> > pops it  
> > clears the shared state. By moving graceful close tot he 
> next higher  
> > layer but providing a mechanism in SPP for the client to use, the  
> > entire problem is simplified and made to work well.
> 
> Yep. The idea I relate above is to report back there is a 
> problem to the router in some form.
> 
> > 
> > There are two kinds of transport layer security: securing the 
> > data in  
> > the channel, and securing the channel. These might be TLS 
> and IPsec  
> > in our environment, or there might be other solutions. 
> Statistics is  
> > the province of a statistical entity, I should think, but probably  
> > has support in the instrumented entity.
> 
> Agree strongly with last sentence.
> 
> > 
> > > Implementation Questions:
> > >
> > > - What are the ramifications to current installed base 
> > networks and  
> > > applications?
> > 
> > I think you have to assume that there will be a long coexistence  
> > period. People will switch from a to b as vendor software enables  
> > them to and as they are motivated to turn it on. Think in terms of  
> > successful solutions being ones that result in tangible monetary  
> > benefits both to the end user and the the providers of the services.
> 
> Agree.
> 
> > 
> > > - What could be done with APIs?
> > 
> > A lot. Can't comment further without more detail on what they are  
> > APIs from and to.
> 
> Yep.
> 
> > 
> > > Transition Questions:
> > >
> > > - Is a transition from TCP/UDP required?
> > 
> > I think not, but there is an enhancement to TCP that is 
> > required, and  
> > I would suggest that migrating from UDP to SCTP has value.
> 
> Yes but still believe TCP needs to die over time.
> 
> > 
> > > - If yes what would be the needs of such a transition?
> > >
> > > - What would be the engineering costs of such a transition?
> > >
> > > - How disruptive would the transition be to those using the  
> > > specifications from the IETF for their Internet Architecture?
> > >
> > > - Who are the non IETF stakeholders?
> > >
> > > This is the type of discussion that is required in some 
> format as  
> > > opposed to just a stream of consciousness.
> > 
> > Yes.
> 
> Yep if we can just talk like this and keep focus we can at a 
> minimum identify a work item for next steps is my thinking.
> 
> Thanks
> /jim
> > 
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/architecture-discuss
> > 

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/architecture-discuss