Re: Thoughts about layering multi-addressing

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 19-aug-2005, at 16:33, marcelo bagnulo braun wrote:

> In addition, i guess that the shim will need to provide some form  
> of support for expressing policy/preferences.
> I guess that the additional complexity in this case, is that these  
> preferences are per ULP rather than per ULID... but this brings us  
> to a more general problem, which is: how do we handle the case  
> where there are two ULPs communicating with a given shim context  
> but they are asking to use different locators for the communication?

Well, for outgoing packets that shouldn't be a problem. If the FTP  
application wants to use the cheap high bandwidth link while the VoIP  
application wants to use the lower bandwidth, more expensive but  
bounded-delay link, the shim can just insert the right addresses and  
send the packets toward the right next hop and everything will work  
fine.

At the remote end, there really isn't much to do: the packet is  
received and the ULIDs rewritten, and that's that. The problem starts  
when we want the other side to send back their bulk data to the  
address tied to our cheap fast line and their VoIP data to the  
address tied to our high quality line.

One way to handle this would be to assume that the apps on the other  
side tell the shim what they want and things will work out without  
specific action from us. The other side still needs to know the  
characteristics of our addresses/links, though. So we need a good way  
to express them. A simple way to do this is two metrics: a high  
priority one, that makes sure only addresses with the highest value  
are chosen when those are available, and a second tie breaker metric  
that can be used for load balancing. So when there are two addresses  
with the highest priority and one as 25 for the second metric and the  
other 75, there is a 75% chance that the second address is used.

We can use the good old low delay/high bandwidth/high reliability bit  
mask to differentiate between the needs of different applications,  
but I'm not sure if this will work out in practice.

Another approach would be for the application on our side to ask the  
transport and for the transport to ask the shim for a certain  
behavior, such as "make incoming traffic for this FTP app come in at  
address X if possible", and the shim communicates this request to the  
shim layer at the correspondent, which then takes the appropriate  
action.

Note that there is no real reason to do a full "fork" of the shim  
state: the most important thing the shim has to do is allow for the  
rewriting and demux of packets. The rewriting is impacted, but not  
the demux. In fork terminology: rather than fork off a new process,  
we're starting a new thread within the same process, which isn't  
nearly as heavy an operation. I think all of this can happen based on  
transport demux info (i.e., port numbers).

It's interesting to note that by now we have several types of  
communication happening at several levels of granularity:

- service differentiation information that is ULP session specific
- rewriting, which happens based on ULID (or more than just ULID if  
we for the ULID state??? what would be the secondary differentiator?)
- demuxing, which is mostly specific to ULIDs but needs help from  
something else (flow label, tag, locator set)
- reachability detection, which happens address pair to address pair
- reachability acks, which happen from host to host