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

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

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