Subject: [ippm] Type-P-Reordered Dst param

From: "Spiros Spirou" <[email-masked]>
Date: Wed, 16 Nov 2005 15:13:29 +0100

Hi,

In section 3.2 of draft-ietf-ippm-reordering-10 the Dst parameters of the
Type-P-Reordered is defined as "the IP address of a host". I assume that
this is not the destination IP field of the packet's IP header because
multicast and broadcast IPs don't qualify as "host IPs". So, is it correct
to report the unicast IP address of the interface that the packet was
received on (think about multihomed receivers)? Which IP should be reported
in case of multiple unicast IPs on the receiving interface?

Thanks,

Spiros

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 16 Nov 2005 15:19:07 +0100

>in case of multiple unicast IPs on the receiving interface?

This comes from the framework and (AFAIK) multiple interfaces or interfaces
with multiple addresses were not discussed when the framework was built.

However, Src and Dst are there to identify the host that sent or received
the packet(s) in the test.  If a host has multiple interfaces or multiple
addresses on an interface, I'd report the address that was actually used.
This uniquely defines the host and also allows one to select traffic
based on the path it took.   Packets sent from/to eth0 may be treated
differently than to eth1, packets sent from/to 192.168.0.0/24 may be
treated differently than packets sent from/to 192.168.1.0/24.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Nov 2005 14:31:55 -0500

Hi Spiros,
adding to Henk's reply, below:

>with multiple addresses were not discussed when the framework was built.

The framework is Unicast-oriented (there are no instances of "multicast"
or "broadcast" in the text of RFC 2330), and Dst is consistently defined
as above in all current IPPM RFCs.  Unicast was the right place to
start, and IPPM's first foray into the world of one-to-many is the
multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt

In the Reordering draft, section 2.3
"Required Context for All Reordering Metrics" gives the opportunity
to report any and all relevant information under the
"Packet of Type-P" category (including transport addresses).

Al

---

From: "Spiros Spirou" <[email-masked]>
Date: Fri, 18 Nov 2005 10:03:01 +0100

Hi Henk,

Thanks for the answer. Please see comments below.

> addresses on an interface, I'd report the address that was actually used.

This works when the address that was actually used is unicast. If you
consider reception of multicast (or broadcast) flows on an interface
configured with multiple (unicast) IPs then it's not clear which one you
should report.

Spiros

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 18 Nov 2005 10:59:47 +0100

>configured with multiple (unicast) IPs then it's not clear which one you

I don't think the standard says which one you should report.  However, if
there are 2 addresses on an interface, then I'd report the address that
the packet was sent to.  (I.e. eth0 has address 1 and 2, a packet is sent
to 2, report 2).

Henk

---

From: "Spiros Spirou" <[email-masked]>
Date: Fri, 18 Nov 2005 12:54:41 +0100

Hi Henk,

> the packet was sent to.  (I.e. eth0 has address 1 and 2, a packet is sent

When the packets have been sent to a multicast group (i.e. the Destination
IP field of the IP header is a valid Class D address), I think that one
cannot do what you're suggesting, because the standard requires reporting a
"host IP" and multicast IPs do not qualify as such.

Spiros

---

From: "Spiros Spirou" <[email-masked]>
Date: Fri, 18 Nov 2005 13:49:44 +0100

Hi Al,

> multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt

For one-to-group metrics the multimetrics draft uses a list (Recv1,...,
RecvN) of "the IP addresses of the N hosts acting as receivers" instead of
the Dst parameter. Still, in the case that receiver j is multihomed should
Recvj be the unicast IP of the interface that received the packet(s)?.
Furthermore, as I already commented to Henk's reply, for an interface
configured with multiple IP that receives the multicast (or broadcast) flow
what should Recvj be?

> "Packet of Type-P" category (including transport addresses).

I would prefer not to abuse the elasticity provided by section 2.3 because
it might undermine the draft's intention, which, in my mind at least, is to
define a common "language" for reporting reordering. IMHO, multicast traffic
is not that uncommon to be handled by the "extension mechanism" of the
draft.

Spiros

---

From: Lei Liang <[email-masked]>
Date: Fri, 18 Nov 2005 12:45:26 +0000

Hi, falks,
  It does make sense now. Actually, in all previous IPPM RFCs, they have
the similar descriptions regarding "host IP". this is because there were
no so much efforts on the multicast/broadcast or one-to-many
communications when they were written. This also includes the framework
RFC. The solution is actually simple as we put in the multimetrics draft
by specifying both multicast group address and the address of the
measurement point. In that case, please see the comments in line.

> Recvj be the unicast IP of the interface that received the packet(s)?.
yes. The "HOST IP" is trying to identify the measurement point itself
physically in the metric and distinct metrics collected on each
measurement point. In the multimetrics draft, these measurement points
are called points of interest.

> configured with multiple IP that receives the multicast (or broadcast) flow
Personally, I think the IP address Recvj should report in the metrics
could be anyone of its IPs as long as all metrics use the same IP. As
said above, this is only to identify Recvj from other receivers.

> is not that uncommon to be handled by the "extension mechanism" of the
I don't know that the metrics of reordering should actually report
whether unicast of multicast coz the operation will not be affected by
any transport mechanism. But I'd leave this question to Al.

---

From: Lei Liang <[email-masked]>
Date: Fri, 18 Nov 2005 13:20:13 +0000

Dear all,
  With respect to the fact that more and more concern have been raised
in the mailing list about multicast/broadcast and the fact that most of
the IPPM RFCs were written oriented to unicast, I think we might need
put more efforts into the Unicast2Multicast or one-to-one2one-to-many
extension or even transition. 
  Personally I think unicast can be viewed as a special case of
multicast/broadcast from the routing point of view. the
multicast/broadcast builds up a routing tree in the networks and unicast
can be viewed as a special simplified tree without branches but only the
"Trunk". This concept can actually be applied to the de/composition
framework that we are trying to achieve in the WG, I think. I.e. we can
try to de/compose the routing(path) tree rather than only mention the
single "trunk"-- unicast path.
  Another concern is, I think, we can make our WG IDs more collaborated
with each other by add words talking about this unicast2multicast
extension/transition. e.g. specify any concern regarding to
multicast/broadcast when necessary in IDs. I will add something to the
multimetric ID with concern of collaboration to the 1 and 2 way active
measurement RFC and ID. 

Regards,

Lei Liang