Re: Thoughts about layering multi-addressing

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

On 24-aug-2005, at 1:00, Erik Nordmark wrote:

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

Simple: if I'm receiving a large file I would really like it to come  
in over my cheap high bandwidth link rather than by expesive, low  
bandwidth bounded delay link.

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

I'm not sure I understand what you mean... Do you mean A's eth0 or  
B's eth0?

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

This also means we don't have to solve it now, as long as we make the  
protocol extensible enough to allow adding features like this in the  
future.

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

Of course. Then obviously some kind of info about which locators to  
use would trickle down from upper layers. (We'll have to look at how  
that should happen at some point, because we really don't want to do  
complex stuff for each individual packet.)

But I guess I was thinking about the situation where such ULP info on  
what should happen isn't available...

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

Yes, but this immediately begs the question: how is this table of  
port numbers maintained? (BTW I wouldn't want to do VoIP over GRPS:  
you get the worst of two worlds.)