[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts about layering multi-addressing



Iljitsch van Beijnum wrote:
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.

That's a motivation for traffic engineering type activities where some network or system admin controls things. But it was your use of "application" above that made me ask the question. Is there a case where it makes sense to have the *application* do this?

If we go that path it would seem to entail a lot of work - adding
options to control this to scp, wget, firefox, ...

I think we need to understand the larger "TE-like" requirements that shim6 can reasonably satisfy, and see if the administrators control can be used to address this example, and not assume that the application will be involved.

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?

A telling B to send its packets out over 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.

To some degree, but we either need to make the shim6 protocol capable of carrying a way to specify the preferences when sending packets in the return direction, or decide that it is the application protocol which will be used to communicate these preferences.


   Erik