Re: Thoughts about layering multi-addressing

[Erik Nordmark <erik.nordmark@sun.com>]

Iljitsch van Beijnum wrote:

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

Yep.

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

It isn't clear for me what the motivation is for such an approach. It 
seems quite odd for the application on A to say something about which 
path B is using to send packets. If this was really a need, wouldn't we 
already see requests for the ability to the application on A to tell B 
whether to send over the "eth0" vs. "eth1" network interface?

So I'm questioning whether we need this complexity.

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

I think I agree. The sender can use any locator pair - and use different 
pairs for different traffic and the receiver just rewrites it to use the 
ULID. So we don't need different shim6 contexts.

And *if* it turns out that we need the ability for the app on A to 
affect how B sends it packets, then this can be viewed as a locator pair 
preference mechanism which is layered on top of the shim proper. There 
isn't a need to have different contexts to do this, and it doesn't help 
because the granularity would be finer than the ULID pair.

> 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?)

Could this be something passed down from the ULP (prefer a given locator 
pair) for ULPs that are aware of multiple locators? Or a "locator pair 
preference sub-layer" for other ULPs?
One can envision simple examples of such a sublayer in the multihomed 
host case - e.g. a table which indicates that the VoIP port numbers 
should prefer the GPRS interface over the WLAN interface i.e. 
preferences on the local locators.

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

   Erik