Subject: RE: [Monami6] using MH is not a magic "re-use"

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Nov 2006 07:35:37 -0800

But Alex, this happens already in the internet. Routers load balance
traffic on behalf of end nodes every day and the end nodes are not
involved. In a lot of NEMO applications this is still likely to be
sufficient.

What you are arguing for is a *new* thing, with which an end node can
instruct a router on how to route its traffic. I would argue that this
is separate and thus out of scope of the basic functionality needed for
MHs/MRs for flow bindings.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, November 14, 2006 10:27 AM
> To: Monami6 WG
> Cc: Soliman, Hesham
> Subject: Re: [Monami6] using MH is not a magic "re-use"
> 
> Tsirtsis, George wrote:
> > Alex,
> >
> > Static configuration of prefixes is only one way. Routing
> > protocols, Prefix Delegation and other mechanisms are also
> > possible, in which case the HA does not have prior knowledge of
> > such things.
> 
> (Routing protocols do not distribute in any way prefixes to be
> assigned, while DHCP does.)
> 
> How do you see DHCP assign addresses and flow preferences to LFN such
> that MR is authorized to do flow bindings for LFN's IP address?  MR
> snooping the DHCP allocation?  MR allocating to LFN?  These are
> unknowns.  HEsham seemed to say out of scope - but without it flow
> bindings on MR about LFN's IP address are not possible.
> 
> > In any case, what is it that you are proposing exactly?
> 
> Without a proper mechanism for LFN to delegate authorization to MR
> about its preferences MR has no possibility to do flow bindings for an
> LFN - in which case one can't say that flow bindings are for MR,
> they're only for MH, no NEMO.
> 
> I don't think I'm proposing any other thing than keep flow bindings in
> the context of MH only, not for MR.
> 
> I certainly don't want the MR to make a decision on its own about
> which apps on which interfaces to use, when those apps run on LFNs.
> Its LFN who's in charge of its apps.
> 
> Alex
> 
> 
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Nov 2006 17:01:54 +0100

Tsirtsis, George wrote:
> But Alex, this happens already in the internet. Routers load 
> balance traffic on behalf of end nodes every day and the end nodes
>  are not involved.

This is fixed end nodes, not mobiles, with homogeneous links - almost
always stable.

It is also a model where ISP routers load balance traffic, and
subscribers pay for higher quality of service.  In smallest NEMO
contexts (PAN) there wouldn't be such relationships between MR and LFN
- both would be owned by same person.

> In a lot of NEMO applications this is still likely to be 
> sufficient.

Ok.

> What you are arguing for is a *new* thing, with which an end node 
> can instruct a router on how to route its traffic.

Best effort routing should happen without end host involvement.  But
appreciative routing (load balancing, traffic shaping, whatever) are
for end host.

> I would argue that this is separate and thus out of scope of the 
> basic functionality needed for MHs/MRs for flow bindings.

You seem to say not only out of scope, but also MRs have the right to
load-balance regardless of LFNs' preferences; and you seem to agree
NEMO already does that for the prefix.

I agree out of scope.

I don't agree MRs should ever load balance on behalf of LFNs without
proper authorization.

I don't agree MR does anything insecure for MNP (HA prohibits it) and
hence it shouldn't be allowed to do anything insecure for flows either.

We may turn in circles :-)

Let's look at the looping problem: what do MH's preferences become
when connecting to a MR?  If a WimAx-WiFi MH prefers WiFi for http and
the WiMax-WiFi MR prefers WiMax instead, and MH connects through WiFi
to MR doesn't this translate into MH using WiMax for http, despite its
preference being WiFi?

I think we should not claim flow bindings are for NEMO.

Alex