Subject: Re: [Monami6] FW: [Int-area] Lifting up a filter discussion from Monami6

From: Heikki Mahkonen <[email-masked]>
Date: Tue, 20 Feb 2007 09:41:06 +0200

Hi Hesham,

Hesham Soliman wrote:
> Regardless of the approach, the solution we had in mind would transfer flow
> descriptions and binding information between the flow in question and one or
> more of the mobile node's addresses. The sender of this information is the
> mobile node. The receiver is either a correspondent node or another
> intermediate node. If we use the terms HA/MAP then we're implying the use of
> MIPv6. So I'll stick to generic language.

==> I think that the solution you describe in your draft for flow 
bindings might be enough for MIPv6 but it is not sufficient for instance 
in NEMO case (or other non MIPv6 intermediate node case). In the flow 
binding draft it is mandatory for the intermediate node to be able to 
receive a BU message, right?

In NEMO the MNN cannot send a BU message to the MR so the MNN. Because 
of this you would need to write another draft (which would resemble I 
think the one or both of the alternative solutions). Or change the NEMO 
so the MNN can send BU to the MR?

Just as an example. In NEMO the MNN might have a need to set the 
preferred routes for it's traffic into the MR. For instance, think of a 
case where the MNN is a laptop and the user uses a cellular phone with 
multiple interfaces as a MR. In this scenario the user most certainly 
would expect some control over the application flows from the laptop 
trough the phone.

Best regards,

Heikki Mahkonen

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 20 Feb 2007 22:29:25 +1100

Hi Heikki, 

I don't think we need to discuss this on the INT area mailing list so I'll
respond to you on the monami list. I think your analysis is off target but
I'll explain it on monami. 

Hesham 

 > -----Original Message-----
 > From: Heikki Mahkonen [mailto:[email-masked]] 
 > Sent: Tuesday, February 20, 2007 6:41 PM
 > To: Monami6 WG; [email-masked]
 > Subject: Re: [Monami6] FW: [Int-area] Lifting up a filter 
 > discussion fromMonami6
 > 
 > Hi Hesham,
 > 
 > Hesham Soliman wrote:
 > Monami6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/monami6
 >

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Feb 2007 22:49:55 +0200

There were a couple of questions about what list to
use for this discussion -- Lets keep the general
discussion on the int-area list. I thought the topic
deserved a wider audience, and that's still the case.
But if there was some detail about current proposals,
monami6 list works for that better. The question
of what nodes to involve, including hosts under an
MR, did seem important though in terms of thinking
what architecture works for this function.

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Feb 2007 19:35:29 +1100

Hi Heikki, 

I guess Jari wants us to continue this point on the int-area list so I'll
respond to both.
See below.

 > so the MNN can send BU to the MR?

=> No no no :). You've skipped a lot of steps here. First of all, the
current solution does support nemo because the signalling can be sent from
the MR to the HA/MAP. As you probably know nemo does not allow the MR to
send BUs to a CN, so this fully supports nemo. Now, your second point is
about an MNN sending a BU. First, lets be clear that the MNN does not send
BUs to the MR in any spec defined today, so the BU would have to be sent
from the MNN to a CN/HA/MAP. I don't see why this can't be done in
draft-soliman. If you mean that the MNN (more likely a VMN) needs to know
what properties correspond to which prefix advertised by the MR then this
goes back to a separate issue of how the MR informs MNNs of the properties
associated with advertised prefixes. This issue was raised many years ago
(when nemo was a bof) and was recently referred to by Thierry in his
response to a query about this point. Thierry's response was on this thread
so feel free to take a look. 

So the bottom line is the MIPv6 solution does support this case. 

 > would expect some control over the application flows from the laptop 

=> Of course, so if it gets the prefixes from the MR and associated
properties with each one it can make that choice. I don't see the
relationship between this issue and the current discussion on this thread. 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 12:14:09 +0100

Hesham Soliman wrote:
> Hi Heikki,
> 
> I guess Jari wants us to continue this point on the int-area list so
>  I'll respond to both. See below.
> 
>> Hesham Soliman wrote:
>>> mobile node. The receiver is either a correspondent node or 
>>> another intermediate node. If we use the terms HA/MAP then we're
>>> 
>> implying the use of
>> bindings might be enough for MIPv6 but it is not sufficient for 
>> instance in NEMO case (or other non MIPv6 intermediate node case).
>>  In the flow binding draft it is mandatory for the intermediate
>> node to be able to receive a BU message, right?
>> 
>> In NEMO the MNN cannot send a BU message to the MR so the MNN. 
>> Because of this you would need to write another draft (which would
>>  resemble I think the one or both of the alternative solutions). Or
>>  change the NEMO so the MNN can send BU to the MR?
> 
>  current solution does support nemo because the signalling can be 
> sent from the MR to the HA/MAP. As you probably know nemo does not 
> allow the MR to send BUs to a CN, so this fully supports nemo.

Yes both Hesham and Heikki: MNN doesn't send NEMO BU and MR doesn't send
BU toCN.

(terminology: MNN as defined  by terminology documents is a Mobile
  Network Node, thus a Mobile Node, which can be a Mobile Router; but I
  assume the intent was to say a MH (not a MR) that is connected to a
  moving network doesn't send BU to MR - I agree with this).

> Now, your second point is about an MNN sending a BU. First, lets be 
> clear that the MNN does not send BUs to the MR in any spec defined 
> today, so the BU would have to be sent from the MNN to a CN/HA/MAP. I
>  don't see why this can't be done in draft-soliman. If you mean that 
> the MNN (more likely a VMN) needs to know what properties correspond 
> to which prefix advertised by the MR then this goes back to a 
> separate issue of how the MR informs MNNs of the properties 
> associated with advertised prefixes. This issue was raised many years
>  ago (when nemo was a bof) and was recently referred to by Thierry in
>  his response to a query about this point. Thierry's response was on 
> this thread so feel free to take a look.

Regardlessof Thierry mentioning it, it's still unsolved.

It's still true that an LFN/MH has certain preferences for application,
preferences that aren't currently communicated to MR.  So when MR makes
monami decisions on which interface to use it's monami-relevant only for
that MR, not for LFN.

In this sense, monami filters at MR are irrelevant to LFN.  In which
case one can easily say that monami filters are only for MR.  Which is
easy to say that is relevant only for the MH part of that MR.

My reasoning is.  But let me turn it into a question:

What's the effect of MR monami filters on the LFN application?

>> preferred routes for it's traffic into the MR. For instance, think
>>  of a case where the MNN is a laptop and the user uses a cellular 
>> phone with multiple interfaces as a MR. In this scenario the user 
>> most certainly would expect some control over the application flows
>>  from the laptop trough the phone.
> 

I agree with you with the first part.  But I see a strong relationship
of MR making monami decisions and its effects on LFN.  If this
relationship is not defined then one simply can't say Monami is for 
NEMO.  End-to-end arguments can be made about this.

I also think a clear distinction should be made here, that I wanted to
say since long but things were too hectic at that time.

When monami6 was formed there network mobility was an important topic
discussed in many places.  Monami6 has a goal to work in the NEMO
context, so it helped building it up.  This can be understood in two ways:

-simplest: NEMO is an extension to MIP, so a HA doing NEMO can be
  extended to do monami (mcoa) and it will continue to do NEMO no
  problem.  But that doesn't mean NEMO protocol was extended.  It more
  means that that HA will continue to use UDP as before, or HTTP or NEMO.
-more complex: have monami flow bindings to have a meaning _through_ the
  MR, to LFN and have a NEMO sense.  That is a more relevant means to say
  that the MONAMI6 WG does NEMO.  OTherwise monami6 does NEMO as much as
  it does UDP.

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 04:37:20 +1100

Alex,  

 > What's the effect of MR monami filters on the LFN application?

=> See below.

 > NEMO.  End-to-end arguments can be made about this.

=> This is not different from a router in the fixed network that
load-balances traffic without informing end hosts. This happens all the time
today and no one is making e2e arguments about that. Routers are given the
authority to route traffic in the most optimum manner, as they see it. 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 19:10:36 +0100

[lifting up monmami6 WG from CC]

Hesham Soliman wrote:
>>>> Just as an example. In NEMO the MNN might have a need to set 
>>>> the preferred routes for it's traffic into the MR. For 
>>>> instance, think of a case where the MNN is a laptop and the 
>>>> user uses a cellular phone with multiple interfaces as a MR. In
>>>>  this scenario the user most certainly would expect some 
>>>> control over the
>> application flows
>> I agree with you with the first part.  But I see a strong 
>> relationship of MR making monami decisions and its effects on LFN.
>>  If this relationship is not defined then one simply can't say 
>> Monami is for NEMO.  End-to-end arguments can be made about this.
> 
> load-balances traffic without informing end hosts. This happens all 
> the time today and no one is making e2e arguments about that.

Hi HEsham, I'm not sure how it's thought routers in the fixed network
load-balance traffic without informing end-hosts.  IETF has some nice
qos reservation mechanisms that are triggered by end-node after which
routers in the middle look at packet markings and load-balance
accordingly.  COPS, RSVP, Traffic Class, Diffserv are keywords for
search.  It's the end-node who tags the packets anyways.

It's even true for a MIP6 HA: HA copies the traffic class from inner to
outer header, so what's decided by MN is respected by HA.  (there's an
option with pre-configured Traffic Class at HA , but optional that is).

So I think flow bindings for NEMO _would_ be different than
COPS/RSVP/Traffic Class, because MR would make decisions irrespective of
the LFN will, what do you think?

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 05:20:42 +1100

> search.  It's the end-node who tags the packets anyways.

=> This is not related to reality in deployed networks. End hosts don't use
RSVP and hosts hardly ever mark TOS fields. Anyway, your response is not
related to what I said earlier, routers do split flows to different links
all the time (of course one flow is expected to take the same path in the
network under normal circumstances). This is a fact and I don't see why an
end host has to know which specific links its traffic goes through on every
hop. That makes no sense. 

 > option with pre-configured Traffic Class at HA , but 

=> Again, this is not related to my comment or this thread in general.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 19:42:35 +0100

[really lifting it from CC this time]

Hesham Soliman wrote:
>> Hi HEsham, I'm not sure how it's thought routers in the fixed 
>> network load-balance traffic without informing end-hosts.  IETF has
>>  some nice qos reservation mechanisms that are triggered by 
>> end-node after which routers in the middle look at packet markings
>>  and load-balance accordingly.  COPS, RSVP, Traffic Class, Diffserv
>>  are keywords for search.  It's the end-node who tags the packets 
>> anyways.
> 
> => This is not related to reality in deployed networks. End hosts 
> don't use RSVP and hosts hardly ever mark TOS fields.

Huh?  RSVP-related RFCs date of last year, recent routers include COPS,
and end hosts routinely mark Traffic Class.  What do you mean hosts
hardly ever mark ToS fields?  You mean IPv4?  I meant IPv6.  Modern
wireless access networks have QoS features too.

> Anyway, your response is not related to what I said earlier, routers 
> do split flows to different links all the time (of course one flow is
> expected to take the same path in the network under normal 
> circumstances).

Routers split flows based on what specs?  I think you agree we can't say
that because some non-specified flow splitting happens then we need to
specify a similar thing.  It means actually we don't want to specify a
similar thing.

> This is a fact

What RFC number?

> and I don't see why an end host has to know which specific links its 
> traffic goes through on every hop. That makes no sense.

It depends.  _If_ the MR decision to choose a different interface is
based on another interface link-down event then it's normal, it's about
keeping connectivity up for the LFN and the LFN can only be happy about
it.  Core routers do the same when selecting paths.

If on the other hand, the decision to choose a different interface is
based on application needs, and MR may _think_ the LFN's application
prefers a certain interface - then it's totally different thing.  And I
believe flow bindings fall into this category, because it has filters on
all possible fields in an application payload.

Have I got this right?

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 06:09:45 +1100

This is really getting away from the relevant monami issues but I'll give
you my last 2 cents.

 > Huh?  RSVP-related RFCs date of last year, 

=> And that means they're used? 

   recent routers 
 > include COPS,
 > and end hosts routinely mark Traffic Class.  

=> I didn't say COPS is not used. I'd love to know about the deployment that
you're referring to (where hosts are setting the TC routinely)...

 > specify a similar thing.  It means actually we don't want to 

=> You seem to think that a product can't implement an algorithm unless it's
specified in an RFC. This is obviously wrong. Anyone can do whatever they
want, hopefully, provided that they don't break existing specs. And that's
the case here.

 > What RFC number?

=> Fact != RFC....

 > all possible fields in an application payload.

=> No. I don't think you understand that routers can select any next hop
they think is appropriate. Link down/up events are only one factor in this
selection. This is a perfectly acceptable behaviour.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 20:36:50 +0100

Hesham Soliman wrote:
> This is really getting away from the relevant monami issues but I'll 
> give you my last 2 cents.
> 

Would you like _your_ flow bindings document to become an RFC and one
year later people say it doesn't mean it's used just because it has an
RFC number on it.

>> include COPS, and end hosts routinely mark Traffic Class.
> 
> => I didn't say COPS is not used. I'd love to know about the 
> deployment that you're referring to (where hosts are setting the TC 
> routinely)...

Well TC marking is used in my lab, works according to specs.

All MIPv6 implementations supposedly use it too, because the MIP6 spec
says so.

>> Routers split flows based on what specs?  I think you agree we 
>> can't say that because some non-specified flow splitting happens 
>> then we need to specify a similar thing.  It means actually we 
>> don't want to specify a similar thing.
> 
> => You seem to think that a product can't implement an algorithm 
> unless it's specified in an RFC.  This is obviously wrong.

I agree with you if I implied so.  But no, far from me that idea.  I
think it is a very good idea in some contexts to do just that, specify
locally (non-IETF) a protocol, implement test debug and benefit from the
feature (sell other things in the mean time).  Google features (earth,
sitemaps, and more) are just that, widely used, and so on.

Remark in the case of Google, although the methods are not standardized,
they're publicly documented, so we can talk about sitemaps.

> Anyone can do whatever they want, hopefully, provided that they don't
>  break existing specs.

I agree.

> And that's the case here.

No no, it's different.  An assumption is made on the behaviour of the
network and no proof is given.  I'm not even mentioned a protocol name
that is not IETF and that does that flow splitting for an uncoscious
endnode.  Doesn't mean I don't believe it exists - it may very well.

But flow splitting can happen in so many different ways that some of
them may be in support of your proposal of MR doing flow bindings on
behalf of LFN, others against.

Being silent about what you mean (what non-IETF flow splitting is widely
used?) means that I can't understand you.

What if for example the flow splitting you mean happens in a network
where only two types of applications are possible, with the
distinguisher being WAP or TCP/IP.  The network indeed splits the flows
and gives more ressources to WAP and less to TCP/IP.  But it is still
the endnode to decide to use either WAP or TCP/IP.

With flow bindings draft we can't say we choose WAP vs TCP/IP, it's just
TCP/IP.  The flow bindings draft qualifies only on TCP/IP parameters.

> => Fact != RFC....

This is very disappointing.  Because it means _your_ draft could become
an RFC and thus a non-fact.

>> If on the other hand, the decision to choose a different interface 
>> is based on application needs, and MR may _think_ the LFN's 
>> application prefers a certain interface - then it's totally 
>> different thing.  And I believe flow bindings fall into this 
>> category, because it has filters on all possible fields in an 
>> application payload.
>> 
>> Have I got this right?
> 
> => No. I don't think you understand that routers can select any next 
> hop they think is appropriate. Link down/up events are only one 
> factor in this selection. This is a perfectly acceptable behaviour.

Ok, let me try cool down.  I agree routers select a next hop they think
appropriate w/o endnode involvement.  That selection happens based on
the src and dst address and the traffic class, all being set by the endnode.

You seem to say other routers do it differently, not looking at any
field, or changing some of the fields.  You don't say what exactly
method is used.  But you say that because other fixed routers don't care
of LFN then MR could either.

I think that is not enough of support for flow bindings monami6.

I also think that the flow binding monami6 methods could make a lot
sense _if_ the MR were informed by the LFN of LFN's preferences.  This
is the crux of our argument and we differ - you say flow bindings
monami6 don't need that LFN preferences.  And knowing that in NEMO WG
they look _probably_ at exactly MR communicating with LFN for parameter
exchange for RO then I think they should be done in tandem.  Ie flow
bindings in monami6 aren't possible w/o RO in NEMO.

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 22 Feb 2007 07:08:16 +1100

> All MIPv6 implementations supposedly use it too, because the 

=> What are you talking about? RFC 3775 doesn't say a host should set the TC
field. 

<snip>

 > field, or changing some of the fields.  

=> I never said that. That would be nonesense.

   You don't say what exactly
 > method is used.  

=> I said they do it on a per-flow basis, meaning a flow is expected to take
the same path in the network. But two different flows can take different
paths. 

 > sense _if_ the MR were informed by the LFN of LFN's 
 > preferences.  

=> That's fine, but as I mentioned earlier (and so did Thierry) this is a
separate point and can augment any proposal.

   This
 > monami6 don't need that LFN preferences.  

=> You must be reading different text from what I wrote, I never said that.
I said it's a separate issue and I hope it gets solved. It's orthogonal to
the choice of protocol, which is what Jari's thread was about.

   And knowing that in NEMO WG
 > bindings in monami6 aren't possible w/o RO in NEMO.

=> Sorry, I don't know what you're talking about.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Feb 2007 21:58:04 +0100

Hesham Soliman wrote:
>>> deployment that you're referring to (where hosts are setting the 
>>> TC routinely)...
>> 
>> All MIPv6 implementations supposedly use it too, because the MIP6 
>> spec says so.
> 
> => What are you talking about? RFC 3775 doesn't say a host should set
>  the TC field.

Ok, rfc3775 requires both the MN and the HA to use generic encapsulation 
with a written reference to another RFC that says when encapsulating 
copy the traffic-class field (optionally pre-configure it).  Which means 
that if MN decides to use a certain class then the intermediary router 
HA respects its decision.  Right?

So is Traffic Class actually used?  I'd say yes, by and large.

>>> => No. I don't think you understand that routers can select any 
>>> next hop they think is appropriate. Link down/up events are only
>>>  one factor in this selection. This is a perfectly acceptable 
>>> behaviour.
>> 
>> Ok, let me try cool down.  I agree routers select a next hop they 
>> think appropriate w/o endnode involvement.  That selection happens
>>  based on the src and dst address and the traffic class, all being
>>  set by the endnode.
>> 

So you didn't say core routers don't look at any fields, didn't say core
routers dont change some fields (in order to achieve their flow
splitting).  Since this is undocumented in an RFC, the only thing I
could is to ask you how do you think the core routers do this flow
splitting?

>> You don't say what exactly method is used.
> 
> => I said they do it on a per-flow basis, meaning a flow is expected
>  to take the same path in the network. But two different flows can 
> take different paths.

Is a 'flow' an application-level flow, like srcport-dstport go this path
and other pair other path?  Or is it a dstaddress-based 'flow'?  Or is
it a src-dst flow?  Are there other distinctors than address and port?

Does the endnode learn at any time what paths and path selection are
used by the core routers (signalling from router to endnode)?

If I understand these, then I can say whether that particular deployment
is in support of flow bindings monami6 w/o LFN involvement make sense or
not.

I'm very surprised when it's said that Traffic Class isn't used and 
other method is in wide use (flow splitting) but can't characterize it 
more than just flows taking different paths.

>>  sense _if_ the MR were informed by the LFN of LFN's preferences.
>> 
> 
> => That's fine, but as I mentioned earlier (and so did Thierry) this
>  is a separate point and can augment any proposal.

In a sense yes, I agree it's separated issue, like one can HTTP between
two endnodes and then UDP between one of these nodes and a third.

But remark HTTP and UDP have IP in common, use IP header fields in the 
same way.  With flowbindings context if one wants to use RSVP on LFN and 
flow balancing according to the Traffic Class in the MR (all specified 
currently) then this will not work, because you suggest that MR uses the 
Flow Identification Option for this classification, or the MR uses the 
Traffic Class.

So at this point Traffic Class fields and Flow Identification Options
are competitors.  It's not like HTTP and UDP both use IP in the same
way, now you have Flow Identification Options and Traffic Class trying
to do same thing.

>> This is the crux of our argument and we differ - you say flow 
>> bindings monami6 don't need that LFN preferences.
> 
> => You must be reading different text from what I wrote, I never said
>  that. I said it's a separate issue and I hope it gets solved.

What if solving that issue means actually using Traffic Class?  Doesn't
it mean that solving that issue means Flow Identification Option isn't
used?  Which of the two RFCs will be used?  Which will be a fact?

> It's orthogonal to the choice of protocol, which is what Jari's 
> thread was about.

I think choosing a flow bindings protocol (among three) drafts is
indeed a separate issue.  I think then that this issue of competition
between Traffic Class and Flow Identification Option (or Filter Rules in
  draft-larsson-monami6-filter-rules-01.txt or Policy Data Set in
draft-mitsuya-monami6-flow-distribution-policy-02.txt) is a second issue.

For example, if there's a means that any of these three drafts rules
makes use of the Traffic Class pre-defined in an RFC (assured
forwarding, etc) then I think I'm basically fine.

I'm also very fine if there's a means for LFN to tell MR via this
Traffic Class field what class it prefers, and fine if MR copies the
Traffic Class field.

>> And knowing that in NEMO WG they look _probably_ at exactly MR 
>> communicating with LFN for parameter exchange for RO then I think 
>> they should be done in tandem.  Ie flow bindings in monami6 aren't
>>  possible w/o RO in NEMO.
> 

Well, as you know in the NEMO WG there's been rechartering to identify
requirements for Route Optimization.  While gathering these
requirements, it may be found out that LFN wants to send the BU to HA
(instead of MR sending BU for its prefix).  For LFN to do that, it may
be that MR sends to LFN what are the subnets to which it connects.  At
that point the flow bindings should be established by LFN somehow.

Or, this may be a solution to the problem we discussed, that LFN knows
nothing about MR decisions and that is bad.  That's why I'm saying NEMO
RO and flow bindings for NEMO are tightly related.

There may be additional issues directly related: one would want to make
sure that when NEMO RO is used and LFN sends a BU, it's the Flow
Bindings specified by that BU that prevail, and not the Flow Bindings in
the BU MR would send.

Now more clear?

Alex