Re: Thoughts about layering multi-addressing

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

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