Re: [arch-d] What Problems are We Solving for the Internet Architecture

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 designed for  
a different problem than TCP. 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.

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.

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. 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.

> 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.

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.  
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.

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.

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?

> - 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. 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.

> - 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".

> - 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.

> - 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...

> - 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.

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.

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.

> 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.

> - What could be done with APIs?

A lot. Can't comment further without more detail on what they are  
APIs from and to.

> 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.

> - 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.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss