Re: [lmap] Missing concept from draft-eardley-lmap-terminology-01.txt

[Matt Mathis <[e-mail]>]

Oops, You are correct, I was looking at -ippm-lmap-path-, and not
-terminology.  My bad

I am not as interested in comparisons between ISPs using
different technologies as I am in having methodology that most accurately
portrays each portion of the path.

Consider issues of cross traffic: for the unshared portion of the path it
is important to test when the user is not using their service, so I can
measure the raw capacity of their access link.   For the shared portion of
the path, I am typically more interested in precisely the opposite
question - does the ISP have sufficient capacity to carry their aggregate
load under normal conditions.   My measurement strategy is to somehow place
a real or virtual MP at the aggregation point, and measure the performance
between an external MP and the aggregation point, under actual load.

For the shared portion of the path, excluding data points due to load
is precisely the wrong thing to do, and raises questions about sampling
bias if the virtual MP is actually placed on a subscriber's premise, and
data has to be discarded when the subscriber is active.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.


On Wed, May 15, 2013 at 1:10 AM, <[e-mail]> wrote:

> << I would like to have precise but technology independent terms for the
> boundary between shared and unshared access resources>>****
>
> This seems a nice idea to me****
>
> ** **
>
> As you say, different technologies have the shared/unshared boundary at
> different distances from the customer. This means that great care is needed
> if comparing results to the “sharing point” in two different networks****
>
> ** **
>
> I also agree that having a virtualised example would be good.****
>
> ** **
>
> Ps think you’re referring to
> http://tools.ietf.org/html/draft-morton-ippm-lmap-path-01 ? - though an
> open question whether any of the terms from there should be migrated into
> http://tools.ietf.org/html/draft-eardley-lmap-terminology-01 – might be
> nice to have them all in one place? Although organisationally one draft
> sits in ippm and the other in lmap ****
>
> ** **
>
> Thanks!
> phil****
>
> ** **
>
> *From:* Matt Mathis [mailto:[e-mail]]
> *Sent:* 13 May 2013 00:49
> *To:* Eardley,PL,Philip,TUB8 R
> *Cc:* [e-mail]
> *Subject:* Missing concept from draft-eardley-lmap-terminology-01.txt****
>
> ** **
>
> Most of the terminology in this draft defined by routing and addressing
> concepts.   For measurement, it is also important to have terminology to
> describe traffic aggregation.  Especially important is over which subpaths
> might one customer's traffic be subject to resource contention with other
> customers?****
>
> ** **
>
> I would like to have precise but technology independent terms for the
> boundary between shared and unshared access resources.   Note that for many
> technologies (mobile service, DOCSIS) this is very close to the service
> demarc at the customer.  For others, such as FTTH and DSL it typically
> occurs in centralized location.****
>
> ** **
>
> The measurement problems on either side of this boundary are extremely
> different, and we need to be able to unambiguously make this dichotomy.***
> *
>
> ** **
>
> I use "unshared access", "shared access", and "sharing point."   Note that
> for many technologies the sharing point is L2 or lower, so there might not
> a natural way to connect a MP at the sharing point.****
>
> ** **
>
> There is also the risk that addressing and routing are going to become
> progressively less relevant as more and more of the network becomes
> virtualized through such technologies as software defined networks.    I
> consider ownership (responsibility), traffic aggregation and resource
> contention to be far more important than addressing.****
>
> ** **
>
> Also, "Destination host" is a rather odd choice for a content provider.
> Perhaps "core service provider."****
>
>
> ****
>
> Thanks,****
>
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> Privacy matters!  We know from recent events that people are using our
> services to speak in defiance of unjust governments.   We treat privacy and
> security as matters of life and death, because for some users, they are.**
> **
>
> ** **
>
> On Thu, May 2, 2013 at 2:52 AM, <[e-mail]> wrote:****
>
> I updated the draft
> http://tools.ietf.org/html/draft-eardley-lmap-terminology
> Thank-you for all the comments!
>
> (the draft is a possible starting point for terminology for the
> prospective lmap wg)
>
> Best wishes
> phil
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 02 May 2013 09:40
> To: Al Morton; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; Al
> C.Morton; Marcelo Bagnulo
> Subject: New Version Notification for draft-eardley-lmap-terminology-01.txt
>
>
> A new version of I-D, draft-eardley-lmap-terminology-01.txt
> has been successfully submitted by Philip Eardley and posted to the IETF
> repository.
>
> Filename:        draft-eardley-lmap-terminology
> Revision:        01
> Title:           Terminology for Large MeAsurement Platforms (LMAP)
> Creation date:   2013-05-02
> Group:           Individual Submission
> Number of pages: 10
> URL:
> http://www.ietf.org/internet-drafts/draft-eardley-lmap-terminology-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology
> Htmlized:
> http://tools.ietf.org/html/draft-eardley-lmap-terminology-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-eardley-lmap-terminology-01
>
> Abstract:
>    This documents defines terminology for Large Scale Measurement
>    Platforms.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap****
>
> ** **
>