Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

From: Jonathan Hui <[email-masked]>
Date: Mon, 3 Nov 2008 10:02:24 -0800

This draft is an excellent starting point and has already generated a  
lot of good discussion. Here are some of my own comments:

- Section 4.3 and 4.4: I understand that these are important metrics  
with more traditional (higher power) link technologies, but I think  
the description does not sufficiently characterize the challenges in  
LLNs. In general, most of the high-order bits in these metrics will be  
due to communication delays at the link layer (scheduled communication  
as well as conservative backoffs can cause communication delays on the  
order of seconds and even 10s of seconds). This can easily dwarf all  
other delays caused by processing times. For the networks I'm used to  
dealing with, I'd argue that communication latency is much more  
significant than node workload.

- Section 4.5: I'm not convinced that the Data Aggregation attribute  
is best to have within the network layer. Data aggregation is  
application specific. The great thing about route-over is that it  
exposes all of the physical connectivity above IP, and doing so  
supports the construction of higher-layer structures (i.e. overlays)  
that can support things like in-network processing. I personally feel  
that data aggregation is best left for higher layers.

- Section 4.6: I share the same concern with Phil. While even DV  
protocols maintain neighbors, the strict resource constraints of LLNs  
often restrict nodes to maintaining state about a *subset* of their  
neighbors. I do believe that maintaining a node's degree in terms of  
bi-directional links will not fit within the resource constraints of  
typical LLNs in the general case. However, degree is a useful metric  
to have, if we can both define and evaluate it properly.

- Section 4.7: Agreeing with what was mentioned earlier on the list,  
the distinction between Dynamicity (4.7)  and Link Reliability (5.2)  
is not obvious to me. In some sense, we have only marginal control  
over network topology and node behaviors - they are often driven by  
surrounding environmental factors.

- Section 5.1: I think the metric we really want here is throughput.  
Bandwidth is only one of many factor that affects the link's throughput.

- Section 5.2: Just a personal opinion here, but I strongly believe  
that bi-directional link success rates (PRR) will be much more useful  
than directional success rates. Due to the lossy nature of LLNs, I  
expect most, if not all, LLNs to utilize link-layer acknowledgments.  
Furthermore, enforcing metrics to be bi-directional have significant  
simplification advantages with respect to routing.

- Section 5.3: I suggest renaming this attribute to Path Delay to  
better describe the latency of delivering a message across the entire  
path. Propagation Delay has already caused some confusion on this list  
and, as traditionally defined, is fairly insignificant compared to the  
other causes of delivery delays.

- Section 5.4: As mentioned with 5.2, bi-directional links are not  
just important for routing, but to enable the use of link mechanisms  
such as link-layer acknowledgements. Are there others that feel  
strongly against preferring routes that support relatively good bi- 
directional communication?

- Section 6: I think it's best to leave the first paragraph in and  
strike the remaining two. It's useful to give the warning, but we  
don't have to explain how to address it in this draft.

--
Jonathan Hui

On Oct 20, 2008, at 10:14 PM, JP Vasseur wrote:

> Dear WG,
>
> As you know, routing metrics for LLN are part of our WG charter.  
> draft-mjkim-roll-routing-metrics-01 is a first draft attempting to  
> list a set of link and node metrics candidates. We intentionally  
> left a wide set of metrics of various nature: link/node, static/ 
> dynamic, ...
>
> We of course have to be quite careful here: defining metrics is one  
> thing, determining what to do and how to make a careful use of it is  
> the hard part. There is a number of notorious examples where metrics  
> have been defined but have never been used simply for a number of  
> reasons:
>  	• Computing an aggregated metric as a polynomial function of a set  
> of metrics is too difficult to operate,
> 	• Use of a set of attributes as hierarchical constraints implies  
> heavy policy configuration,
> 	• Use of dynamic metrics was the source of routing oscillations  
> (e.g. ARPANET)
> 	• ....
>
> So we would need your feed-back, bearing in mind that we may want to  
> only keep the metrics that are critical to LLNs.
>
> Waiting for your comments ...
>
> Thanks.
>
> JP and Kim.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "MiJeom Kim" <[email-masked]>
Date: Tue, 4 Nov 2008 16:46:29 +0900

Hi, Jonathan, really appriciate your valuable comments. Please see below.

On Tue, Nov 4, 2008 at 3:02 AM, Jonathan Hui <[email-masked]> wrote:
>
> - Section 4.3 and 4.4: I understand that these are important metrics with more traditional (higher power) link technologies, but I think the description does not sufficiently characterize the challenges in LLNs. In general, most of the high-order bits in these metrics will be due to communication delays at the link layer (scheduled communication as well as conservative backoffs can cause communication delays on the order of seconds and even 10s of seconds). This can easily dwarf all other delays caused by processing times. For the networks I'm used to dealing with, I'd argue that communication latency is much more significant than node workload.
>
> ==> I totally agree on what you said here. However, L2 delay depends on MAC protocols and it's very fluctuating by time. If there is high contention for a given channel, it takes more time to send a packet with contention based protocols. In contention-free protocols, L2 delay is more predictable and consistent. Due to the all dependency, I do not think it is possible to make L2 delay as a routing metric.
>
> - Section 4.5: I'm not convinced that the Data Aggregation attribute is best to have within the network layer. Data aggregation is application specific. The great thing about route-over is that it exposes all of the physical connectivity above IP, and doing so supports the construction of higher-layer structures (i.e. overlays) that can support things like in-network processing. I personally feel that data aggregation is best left for higher layers.
>
> ==> I agree that data aggregation is application or traffic dependent. Let's hear other's opinion.
>
> - Section 4.6: I share the same concern with Phil. While even DV protocols maintain neighbors, the strict resource constraints of LLNs often restrict nodes to maintaining state about a *subset* of their neighbors. I do believe that maintaining a node's degree in terms of bi-directional links will not fit within the resource constraints of typical LLNs in the general case. However, degree is a useful metric to have, if we can both define and evaluate it properly.
>
> ==> As I mentioned already, we need to reach consensus on the way to evaluate node degree. Higher degree would be preferable, but does this apply for all situations? Also, we need to evaluate trade-off between cost and benefit of using node degree as a metric.
>
> - Section 4.7: Agreeing with what was mentioned earlier on the list, the distinction between Dynamicity (4.7)  and Link Reliability (5.2) is not obvious to me. In some sense, we have only marginal control over network topology and node behaviors - they are often driven by surrounding environmental factors.
>
> ==> we can't control the dynamicity or reliability. We just need to monitor and estimate them to construct a better path by avoiding highly dynamic and unreliable nodes. We need to have clear definitions for them and methods to measure them, which is challenging.
>
> - Section 5.1: I think the metric we really want here is throughput. Bandwidth is only one of many factor that affects the link's throughput.
>
> ==> I agree. Actual average data rate can be one factor to affect the throughput. Do you have other factors in your mind?
>
> - Section 5.2: Just a personal opinion here, but I strongly believe that bi-directional link success rates (PRR) will be much more useful than directional success rates. Due to the lossy nature of LLNs, I expect most, if not all, LLNs to utilize link-layer acknowledgments. Furthermore, enforcing metrics to be bi-directional have significant simplification advantages with respect to routing.
>
> ===> I do agree, but maintaining bi-directional metrics costs more in terms of communication and other resources like memory and power.
>
> - Section 5.3: I suggest renaming this attribute to Path Delay to better describe the latency of delivering a message across the entire path. Propagation Delay has already caused some confusion on this list and, as traditionally defined, is fairly insignificant compared to the other causes of delivery delays.
>
> ===> Here, we try to specify all link attributes as metrics. Of course, path delay impacts more on routing decision, but calculating it costs very high and we need to evaluate all possible paths with global view. I think extending to paths from links is not a good idea when considering routing metrics especially in LLNs due to high costs.
>
> - Section 5.4: As mentioned with 5.2, bi-directional links are not just important for routing, but to enable the use of link mechanisms such as link-layer acknowledgements. Are there others that feel strongly against preferring routes that support relatively good bi-directional communication?
> ===> I do agree that there are good reasons to consider bi-directionality. But we also need to consider costs to maintain it and try to find the best way to figure out and keep it.
>
> - Section 6: I think it's best to leave the first paragraph in and strike the remaining two. It's useful to give the warning, but we don't have to explain how to address it in this draft.
>
> ===> I think there is no harm to keep those sentences, which give more information. But we need to revise them, though.
>
> Jonathan Hui
>
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 04 Nov 2008 12:50:53 +0100

Hi Jonathan,

On 11/3/08 7:02 PM, "Jonathan Hui" <[email-masked]> wrote:

> lot of good discussion.

Thanks for the comments,

Here are some of my own comments:
> LLNs. 

JP> Well, except in the case of the "overload" bit used for example for
synchronization purposes between the IGP and BGP (due to slower convergence
of BGP), these metrics are usually not relevant in traditional networks.

In general, most of the high-order bits in these metrics will be
> significant than node workload.

JP> We are in sync. As pointed out in previous emails, the goal of this
first version was to list *all* metrics and trigger a discussion to make
sure that we only keep the *key* metrics.

Anyone on this list thinking otherwise with regards to the node workload and
latency ?

> that data aggregation is best left for higher layers.

Happy to have that discussion, I do think otherwise ;-) You can always build
an overlay at the transport or application layer but that requires to carry
extra information in the payload, address manipulations, discovery
capabilities (to discover the aggregating nodes), ... Etc. By advertising
data aggregation at the routing layer, this allows routing to compute routes
taking into account the node aggregation capability, thus the destination
remains unchanged and the routing engine potentially elect non shortest
paths (=> constrained-based routing) to allow for aggregation.

> to have, if we can both define and evaluate it properly.

OK. Furthermore, the node degree is known in link state and requires
significant amount of states in DV, especially when one performs route
aggregation. Finally it only gives an "idea" of the potential backup routes.

> surrounding environmental factors.

The idea was to have a simple flag used by a node to advertise (when known)
if it is a priori a mobile or static node (e.g. Remote control versus
movement detector) whereas the link reliability is not of course related to
link quality and can significantly vary on nodes with multiple radios or
wired and wireless link.

Don't you see a use of such a static/mobile node flag ?

> Bandwidth is only one of many factor that affects the link's throughput.

Very good point. Totally agree.

> simplification advantages with respect to routing.

Mmm ... That does require discussion. Routing is almost always asymmetrical.
Why would you need symmetrical link metric for routing ?

> path. 

JP> This is typo, yes indeed. Furthermore, Path delay is not a routing
metric carried by the protocol.

Propagation Delay has already caused some confusion on this list
> other causes of delivery delays.

JP> Which leads to the question: "Do we need link propagation delay at all
?"

> directional communication?

JP> I do see any reason for mandating path to be symmetrical ?

> don't have to explain how to address it in this draft.

JP> Well we do need to discuss these issues in the document. We cannot list
a set of metrics without specifying how they will be used and their
implication on the routing protocol dynamics. This is one of these examples
where the metrics settings is not an implementation issues. I could mention
a number of documents where we had to specify such mechanisms in great
details to pass IESG review (for good reasons !).

Thanks for the comments.

Cheers.

JP. 

>> € Computing an aggregated metric as a polynomial function of a set
>> € Use of a set of attributes as hierarchical constraints implies
>> € Use of dynamic metrics was the source of routing oscillations
>> (e.g. ARPANET)
>> € ....
>>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 10 Nov 2008 08:21:31 -0800

Hi MiJeom, see below:

On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote:

>> - Section 4.3 and 4.4: I understand that these are important  
>> metrics with more traditional (higher power) link technologies, but  
>> I think the description does not sufficiently characterize the  
>> challenges in LLNs. In general, most of the high-order bits in  
>> these metrics will be due to communication delays at the link layer  
>> (scheduled communication as well as conservative backoffs can cause  
>> communication delays on the order of seconds and even 10s of  
>> seconds). This can easily dwarf all other delays caused by  
>> processing times. For the networks I'm used to dealing with, I'd  
>> argue that communication latency is much more significant than node  
>> workload.
>>
>> ==> I totally agree on what you said here. However, L2 delay  
>> depends on MAC protocols and it's very fluctuating by time. If  
>> there is high contention for a given channel, it takes more time to  
>> send a packet with contention based protocols. In contention-free  
>> protocols, L2 delay is more predictable and consistent. Due to the  
>> all dependency, I do not think it is possible to make L2 delay as a  
>> routing metric.

[jhui] There are significant constant factors that we can consider  
when considering L2 delay - duty cycle and phase. Both of which  
determine the *minimum* latency. Both of which can be on the order of  
seconds or more.

>> - Section 4.5: I'm not convinced that the Data Aggregation  
>> attribute is best to have within the network layer. Data  
>> aggregation is application specific. The great thing about route- 
>> over is that it exposes all of the physical connectivity above IP,  
>> and doing so supports the construction of higher-layer structures  
>> (i.e. overlays) that can support things like in-network processing.  
>> I personally feel that data aggregation is best left for higher  
>> layers.
>>

[jhui] In some cases, unicast routing is not always the best way to  
aggregate information between nodes that are within physical proximity.

>> protocols maintain neighbors, the strict resource constraints of  
>> LLNs often restrict nodes to maintaining state about a *subset* of  
>> their neighbors. I do believe that maintaining a node's degree in  
>> terms of bi-directional links will not fit within the resource  
>> constraints of typical LLNs in the general case. However, degree is  
>> a useful metric to have, if we can both define and evaluate it  
>> properly.
>>
>> ==> As I mentioned already, we need to reach consensus on the way  
>> to evaluate node degree. Higher degree would be preferable, but  
>> does this apply for all situations? Also, we need to evaluate trade- 
>> off between cost and benefit of using node degree as a metric.

[jhui] Yes. What is degree, really? All nodes that can communicate to  
A? All nodes that A can communicate to? Both? These definitions have  
subtle differences on the use of a degree metric and that is dependent  
on the L2 capabilities below.

>> - Section 4.7: Agreeing with what was mentioned earlier on the  
>> list, the distinction between Dynamicity (4.7)  and Link  
>> Reliability (5.2) is not obvious to me. In some sense, we have only  
>> marginal control over network topology and node behaviors - they  
>> are often driven by surrounding environmental factors.
>>
>> ==> we can't control the dynamicity or reliability. We just need to  
>> monitor and estimate them to construct a better path by avoiding  
>> highly dynamic and unreliable nodes. We need to have clear  
>> definitions for them and methods to measure them, which is  
>> challenging.

[jhui] That's exactly my point. The way we monitor dynamicity and  
reliability may be very similar...

>> - Section 5.1: I think the metric we really want here is  
>> throughput. Bandwidth is only one of many factor that affects the  
>> link's throughput.
>>
>> ==> I agree. Actual average data rate can be one factor to affect  
>> the throughput. Do you have other factors in your mind?

[jhui] The L2 protocol is the largest factor in what throughput you  
can expect on that link.

>> that bi-directional link success rates (PRR) will be much more  
>> useful than directional success rates. Due to the lossy nature of  
>> LLNs, I expect most, if not all, LLNs to utilize link-layer  
>> acknowledgments. Furthermore, enforcing metrics to be bi- 
>> directional have significant simplification advantages with respect  
>> to routing.
>>
>> ===> I do agree, but maintaining bi-directional metrics costs more  
>> in terms of communication and other resources like memory and power.

[jhui] I'd argue the opposite. In many cases, maintaining only bi- 
directional links can be cheaper than trying to maintain a set of  
disjoint directional links, communicating directional links between  
nodes, and generating a workable topology over them.

>> better describe the latency of delivering a message across the  
>> entire path. Propagation Delay has already caused some confusion on  
>> this list and, as traditionally defined, is fairly insignificant  
>> compared to the other causes of delivery delays.
>>
>> ===> Here, we try to specify all link attributes as metrics. Of  
>> course, path delay impacts more on routing decision, but  
>> calculating it costs very high and we need to evaluate all possible  
>> paths with global view. I think extending to paths from links is  
>> not a good idea when considering routing metrics especially in LLNs  
>> due to high costs.

[jhui] All I was saying is that I usually view propagation delay as  
the time it takes for the signal to traverse the medium across a  
single link. Giving it a different name will help remove some of the  
confusion on this list.

--
Jonathan Hui

>> just important for routing, but to enable the use of link  
>> mechanisms such as link-layer acknowledgements. Are there others  
>> that feel strongly against preferring routes that support  
>> relatively good bi-directional communication?
>> ===> I do agree that there are good reasons to consider bi- 
>> directionality. But we also need to consider costs to maintain it  
>> and try to find the best way to figure out and keep it.
>>
>> ===> I think there is no harm to keep those sentences, which give  
>> more information. But we need to revise them, though.
>>
>> Jonathan Hui
>>
>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 10 Nov 2008 17:46:42 +0100

Hi Jonathan,

I'd like to go back to one specific since you referred to it twice: why
would you want bidirectional link metrics ? Where IP routing is inherently
asymmetrical.

Thanks.

JP.

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 10 Nov 2008 09:05:09 -0800

Hi JP,

The root of this, of course, is the limited capabilities of the nodes.  
In general, nodes in LLNs can only maintain state for a (potentially  
small) subset of nodes. The first question is which subset? How do we  
ensure that the joint topology represented by the subset of nodes each  
node picked provides reachability to all nodes? There are ways to  
ensure this, but they are often costly (require floods, elections,  
etc.).

This may seem counterintuitive, but maintaining directional link  
metrics can actually be more costly than maintaining bi-directional  
ones. The directional case implies that the receiver is maintaining  
state about the transmitter. First, for that information to be useful,  
the receiver must communicate that information to whoever is  
performing the routing computations and ultimately that metric/ 
decision based on that metric has to go back to the transmitter.  
Second, it limits the in-degree of the node (nodes that can route  
through the receiver). Instead, if the link provides bi-directional  
success rates using its synchronous acknowledgements, the transmitter  
can maintain state for whatever number of routes it maintains and  
there is no routing limit on the in-degree of the receiver since the  
state is distributed among the transmitters.

Finally, for many of the link technologies that we use today,  
forwarding relies on the use of synchronous acks for hop-by-hop  
recovery. In that case, some measure of bi-directionality is required  
and already provided by the link.

Restricting use to bi-directional links for any arbitrary link is not  
what I really meant. As you pointed out, there are many cases where  
use of directional links is useful (if not required). I was just  
picking an extreme point to see how people would react :-). BTW,  
having bi-directional link metrics does not mean routes have to be  
chosen in a symmetric way.

--
Jonathan Hui

---

From: Kris Pister <[email-masked]>
Date: Mon, 10 Nov 2008 15:50:28 -0800

I agree with Jonathan that aggregation is best left to higher layers.
Is there a requirements document that lists aggregation? In my 
experience this is one of those clever ideas that never has a real 
application. Certainly the concepts of data fusion, distributed signal 
processing, and joint source coding have all enjoyed lots of academic 
interest, but as far as I know no commercial application.
The original vision was that dust would scattered everywhere (jeez, who 
came up with *that* crazy idea :) ) and we'd be required to fuse the 
data just to make sense of it. For industrial and commercial 
applications, the opposite is true - sensors will be placed where they 
are needed, typically measuring things that either have no correlation. 
More importantly, in most applications listed in the various 
requirements documents, all of the data is likely to be encrypted with 
end-to-end session keys that do not admit any en route snooping.
In the interest of keeping an already large set of attributes smaller, I 
recommend that we remove aggregation from the routing layer and let 
higher layers deal with it if they want to.

ksjp

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 12 Nov 2008 11:42:19 -0800

On Mon, Nov 10, 2008 at 8:21 AM, Jonathan Hui <[email-masked]> wrote:
...
> On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote:
...
>>> - Section 4.5: I'm not convinced that the Data Aggregation attribute is
>>> best to have within the network layer. Data aggregation is application
>>> specific. The great thing about route-over is that it exposes all of the
>>> physical connectivity above IP, and doing so supports the construction of
>>> higher-layer structures (i.e. overlays) that can support things like
>>> in-network processing. I personally feel that data aggregation is best left
>>> for higher layers.
>>>

Unless we are talking about self identifying data (and we are not
talking about that), how will aggregation work without application
specific data processing code in the forwarding plane? Even
concatenation will require major assumptions about data layout.

- om_p

---

From: Tim Winter <[email-masked]>
Date: Wed, 12 Nov 2008 18:38:20 -0500

One useful application of aggregation would be in an electricity
metering scenario when a power outage occurs.  In this application many
(previously powered) nodes may find themselves running on a `last gasp'
power source such as a capacitor.  The goal would be allow as many
sensors as possible to relay their outage status before the last gasp
source is exhausted, so that a utility can better pinpoint the region
affected by the outage.
In this scenario, being able to apply a routing strategy to forward data
toward nodes capable of aggregation may allow the network to relay much
more outage information before backup power is exhausted.

-Tim

Kris Pister wrote:
> The original vision was that dust would scattered everywhere (jeez,
> who came up with *that* crazy idea :) ) and we'd be required to fuse
> the data just to make sense of it. For industrial and commercial
> are needed, typically measuring things that either have no
> correlation. More importantly, in most applications listed in the
> various requirements documents, all of the data is likely to be
> encrypted with end-to-end session keys that do not admit any en route
> snooping.
> In the interest of keeping an already large set of attributes smaller,
> I recommend that we remove aggregation from the routing layer and let

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 12 Nov 2008 18:47:19 -0800

> more outage information before backup power is exhausted.

What does the proposed aggregation metric look like? Is it a bit? Is
this metric different from some combination of "resource" metric such
as CPU, RAM, storage, energy? Yes, in theory but in practice there is
probably no difference. If a packet arrives at a node with gigabytes
of storage or uses wall power, it probably does not matter if the data
is aggregated.

- om_p

---

From: JP Vasseur <[email-masked]>
Date: Thu, 13 Nov 2008 11:59:22 +0100

It could be a bit but for the moment let's agree on whether or not we need
it. Personally I would say "yes", others say "No", others say "Yes". I guess
that we have a better consensus toward the yes.
The immediate next step is to discuss the encoding .. Could be a single bit
with optional TLV to carry more data. TO be discussed soon.

Cheers,

JP.

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Thu, 13 Nov 2008 06:29:14 -0800

> that we have a better consensus toward the yes.

I had the impression that there was no consensus at this point.

I still don't understand the difference between CPU/RAM/storage/Energy
metric and aggregation metric in practice.

- om_p

---

From: JP Vasseur <[email-masked]>
Date: Fri, 14 Nov 2008 09:25:42 +0100

Hi,

> metric and aggregation metric in practice.

Both are used for routing of course but the aggregation metric is used to
change the routing decision so as to allow for data aggregation (there could
be multiple data depending on the type of aggregated data); the CPU/RAM or
Energy are used to change the routing decision so as to compute the shortest
*constrained* path.

Hope this helps.

JP.

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Fri, 14 Nov 2008 15:09:45 -0800

> Energy are used to change the routing decision so as to compute the shortest

Thanks. Because this is a metric that reflects software feature of a
node, should there be metrics such as compression, FFT, and things
like that? For aggregation to be possible, we need a forwarding
architecture that allows execution of application specific processing
code in between packet reception and transmission. If there is a
commitment to such a architecture, aggregation and many other metrics
that expose software capability makes sense.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Fri, 14 Nov 2008 15:15:14 -0800

> that expose software capability makes sense.

 From an IP standpoint, aggregation seems problematic. Among other  
things, it breaks end-to-end, not even in the soft way (addresses)  
that NATs do, but by actually changing the payload. This seems to me  
to be a real nightmare scenario. Let's say that the aggregation is  
something as simple as data suppression; this requires the router,  
among other things, to know the transport protocol. No matter that  
data suppression would be an issue for connection-oriented protocols  
such as TCP or DCCP.

Setting up aggregation as a transport-layer overlay seems much more  
feasible. E.g., nodes send UDP traffic to an aggregation point (could  
be single hop), which then aggregates the date and sources new,  
aggregated packets. But this would be a layer 5+ decision, not a layer  
3 one.

Or am I missing something? Perhaps if I had a better sense of what's  
meant by "aggregation," e.g., a concrete scenario, this discussion  
might be more structured.

Phil

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Mon, 17 Nov 2008 13:59:01 -0800

On Fri, Nov 14, 2008 at 3:15 PM, Philip Levis <[email-masked]> wrote:
> From an IP standpoint, aggregation seems problematic. Among other things, it
> breaks end-to-end, not even in the soft way (addresses) that NATs do, but by
> actually changing the payload. This seems to me to be a real nightmare
> scenario. Let's say that the aggregation is something as simple as data
> suppression; this requires the router, among other things, to know the
> transport protocol. No matter that data suppression would be an issue for
> connection-oriented protocols such as TCP or DCCP.
>
> feasible. E.g., nodes send UDP traffic to an aggregation point (could be
> single hop), which then aggregates the date and sources new, aggregated
> packets. But this would be a layer 5+ decision, not a layer 3 one.
>
> Or am I missing something? Perhaps if I had a better sense of what's meant
> by "aggregation," e.g., a concrete scenario, this discussion might be more
> structured.
>

There is a concrete scenario in the draft. Node A sends the data "xyz"
to C. Node B sends the data "xqz" to C. Node C then transmits "xyzq"
to the sink. So scenario is not the problem. The problem is ignoring
the forwarding implications of it as you clearly articulated. I was
surprised that the discussion on this metric was not reflected in the
updated draft. The metric sounds wonderful in theory.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Mon, 17 Nov 2008 14:21:04 -0800

> updated draft. The metric sounds wonderful in theory.

Sure. But what I guess what's confusing about that example is the  
source address the packet C sends and the destination addresses of the  
packets A and B send. If the answer to all of these three questions is  
"C", then it's not occurring in the routing layer. It's a not a  
routing metric, but rather, a metric for a routing overlay on top of  
IP. If the answer to any of those questions is not "C," then it's  
breaking end-to-end.

Phil

---

From: "MiJeom Kim" <[email-masked]>
Date: Tue, 18 Nov 2008 10:22:51 +0900

Hi,

If I answer the question Phil asked, the destination of A and B's
packets is the "sink" not C. So it's breaking end-to-end.
I agree that it may not feasible for a node to look at inside of
packets and aggregate them especially with data encryption feature.
However, I kept the original texts for the metric since not many
members gave their opinions on this and we may have more discussion at
today's face-to-face meeting. I would definitely reflect consensus
(hopefully if we reach) on the next revision.

Thanks,
Mijeom.

On Tue, Nov 18, 2008 at 7:21 AM, Philip Levis <[email-masked]> wrote:
> Sure. But what I guess what's confusing about that example is the source
> address the packet C sends and the destination addresses of the packets A
> and B send. If the answer to all of these three questions is "C", then it's
> not occurring in the routing layer. It's a not a routing metric, but rather,
> a metric for a routing overlay on top of IP. If the answer to any of those
> questions is not "C," then it's breaking end-to-end.
>
> Phil