[alto] Fwd: Publication has been requested for draft-ietf-alto-performance-metrics-15

[Jan Seedorf]

Dear all,

here is my write-up for the publication request on 
draft-ietf-alto-performance-metrics:


1. Summary

Jan Seedorf is the document shepherd for 
draft-ietf-alto-performance-metrics. Martin Duke is the responsible Area 
Director.


The ALTO base protocol (RFC7285) defines only a single cost metric, the 
generic “routing cost” metric. As new ALTO use cases are being 
envisioned (e.g. CDN, 5G, data-intensive science applications, flexible 
inter-domain routing, etc.), the demand for more concrete cost metrics 
to be conveyed via the ALTO protocol arises. This document defines a 
multitude of such concrete ALTO cost metrics, such as one-way delay, hop 
count, residue bandwidth, and several more.


This document is targeted as a Standards Track document (Proposed 
Standard). This designation is appropriate as the document contains 
normative behaviour and specifies several additions to the IANA "ALTO 
Cost Metric Registry" that should be adhered to by the communicating 
entities in order to realize the extension.



2. Review and Consensus
The document was introduced originally in 2013 and has been iterated and 
presented at IEFT meetings many times. It was adopted as WG item in 
2016, showing the general consensus in the ALTO WG for adding more 
concrete costs metrics to the ALTO protocol.


The proposed metrics have been discussed extensively at IETF meetings 
and on the mailing list. Since some of these metrics must to be 
specified in an unambiguous fashion with clear semantics, external help 
from IETF experts was obtained: in 2018 a “Tsvart early review” was 
performed by Brian Trammell. The outcome has been discussed on the 
mailing list and has been addressed in newer versions of the document. 
Also, advice from IETF experts from the IPPM WG on the semantics of the 
proposed metrics was obtained, discussed, and incorporated into the 
document. All of these changes and semantics have been presented to the 
ALTO WG multiple times.


In summary, there is clear consensus for 
draft-ietf-alto-performance-metrics in the ALTO WG, and it provides very 
useful cost metric extensions needed for many of the currently 
envisioned (future) ALTO use cases. A WGLC has successfully been passed 
with no objections, and extensive reviews were provided by various 
members of the WG and have all been addressed.



3. Intellectual Property
The shepherd confirms that each author has stated to him that to the 
best of his/her (i.e. the author’s) knowledge, all IPR related to this 
document has been disclosed.



4. Other Points
Note any downward references (see RFC 3967) and whether they appear in 
the DOWNREF Registry 
(http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as 
these need to be announced during Last Call.


All normative references are ok (with respect to RFC 3967) as they are 
all towards documents with standards-level “Proposed Standards”, 
“Internet Standard”, or “BCP”.


 - Jan



 Weitergeleitete Nachricht 
Betreff: 	Publication has been requested for 
draft-ietf-alto-performance-metrics-15

Weitersenden-Datum: Sun, 21 Mar 2021 15:37:17 -0700 (PDT)
Weitersenden-Von:   alias-boun...@ietf.org
Weitersenden-An: 	bill...@huawei.com, vijay.gurb...@gmail.com, 
i...@j-f-s.de

Datum:  Sun, 21 Mar 2021 15:37:17 -0700
Von:Jan Seedorf via Datatracker 
An: martin.h.d...@gmail.com
Kopie (CC): 	alto-cha...@ietf.org, alto@ietf.org, 
iesg-secret...@ietf.org, i...@j-f-s.de, j...@j-f-s.de




Jan Seedorf has requested publication of 
draft-ietf-alto-performance-metrics-15 as Proposed Standard on behalf of 
the ALTO working group.


Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-performance-metrics-15

[Jan Seedorf via Datatracker]

Jan Seedorf has requested publication of draft-ietf-alto-performance-metrics-15 
as Proposed Standard on behalf of the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12

[Jan Seedorf]

Dear authors of draft-ietf-alto-performance-metrics-12,

may I kindly ask about the status and your plans for moving this 
forward? (see below)


Thanks,

Jan

Am 08.11.20 um 22:56 schrieb Jan Seedorf:

Dear all,

this ends the WGLC for draft-ietf-alto-performance-metrics-12. No 
objections on this document have been raised. Three individual reviews 
have been done, the respective comments have each been posted on the 
ALTO mailing list by Kai (Oct 10), Denny (Oct 12), and Jensen (Oct 
13). May I kindly ask the authors of the document to address these 
comments ASAP and post a new version of the document?


Thanks,

Jan

Am 28.09.20 um 18:42 schrieb Jan Seedorf:

Dear all,

as discussed during the ALTO session at IETF-108, we are moving 
forward with all the remaining milestones.


Thus, this email starts a WGLC for 
draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, 
so from today, Monday, September 28, until Monday, Oktober 12, 2020.


We would like to have two individual reviews of this document as part 
of the WGLC. Please send us an email if you are willing review the 
draft as part of WGLC. We really need these reviews to make progress.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Normative References in draft-ietf-alto-performance-metrics-12

[Jan Seedorf]

Dear authors of draft-ietf-alto-performance-metrics-12,

while reviewing the document, I notices the following issues with 
normative references:


1)    [I-D.ietf-idr-te-pm-bgp]
  Previdi, S., Wu, Q., Gredler, H., Ray, S.,
  jefft...@gmail.com, j., Filsfils, C., and L. Ginsberg,
  "BGP-LS Advertisement of IGP Traffic Engineering
  Performance Metric Extensions", draft-ietf-idr-te-pm-
  bgp-03 (work in progress), May 2016.

--> This is an RFC by now, so please fix the ref

2)    [I-D.ietf-ippm-initial-registry]
  Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
  "Initial Performance Metric Registry Entries", draft-ietf-
  ippm-initial-registry-01 (work in progress), July 2016.

--> this draft is in version -016 by now, and also not a normative 
reference; so please update the ref and move it to informative references


Can you please address these issues as well when you address the WGLC 
comments received (see below)?


Thanks,

Jan

Am 08.11.20 um 22:56 schrieb Jan Seedorf:

Dear all,

this ends the WGLC for draft-ietf-alto-performance-metrics-12. No 
objections on this document have been raised. Three individual reviews 
have been done, the respective comments have each been posted on the 
ALTO mailing list by Kai (Oct 10), Denny (Oct 12), and Jensen (Oct 
13). May I kindly ask the authors of the document to address these 
comments ASAP and post a new version of the document?


Thanks,

Jan

Am 28.09.20 um 18:42 schrieb Jan Seedorf:

Dear all,

as discussed during the ALTO session at IETF-108, we are moving 
forward with all the remaining milestones.


Thus, this email starts a WGLC for 
draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, 
so from today, Monday, September 28, until Monday, Oktober 12, 2020.


We would like to have two individual reviews of this document as part 
of the WGLC. Please send us an email if you are willing review the 
draft as part of WGLC. We really need these reviews to make progress.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Welcome Qin Wu

[Jan Seedorf]

Dear Qin,

welcome as new chair for the ALTO WG! Vijay and I will contact you soon 
regarding IETF-109 and how we can manage the planned re-charter 
discussions there most effectively.


 - Jan

Am 11.11.20 um 10:35 schrieb Qin Wu:


Hi, Martin, et al :

Thank for having me.  Jan and Vijay, I am happy to come back to ALTO 
team and help deliver the existing work on the table and in the 
meanwhile, work together with you senior chairs to drive new work 
discussion.


Look forward to working with you soon next week, thanks!

-Qin

*发件人:*Y. Richard Yang [mailto:y...@cs.yale.edu]
*发送时间:*2020年11月11日12:47
*收件人:*Martin Duke ; Qin Wu 


*抄送:*IETF ALTO 
*主题:*Re: [alto] Welcome Qin Wu

Thanks a lot for choosing a wonderful chair for ALTO, Martin!

Qin: It is wonderful to have you and work with your guidance!

Richard

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke > wrote:


Hello ALTO,

I'm pleased to welcome Qin Wu as the newest working group chair,
effective immediately. Qin is and active participant in ALTO and
an experienced chair.

We will have three chairs at IETF 109. Shortly afterwards, one of
the current chairs will step down. As we complete the current
milestones, I will appoint a second chair to free both Jan and
Vijay to move on to other things.

See you next week,

Martin

___
alto mailing list
alto@ietf.org 
https://www.ietf.org/mailman/listinfo/alto



--

--

 =

| Y. Richard Yang mailto:y...@cs.yale.edu>>   |

| Professor of Computer Science       |

| http://www.cs.yale.edu/~yry/         |

 =


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12

[Jan Seedorf]

Dear all,

this ends the WGLC for draft-ietf-alto-performance-metrics-12. No 
objections on this document have been raised. Three individual reviews 
have been done, the respective comments have each been posted on the 
ALTO mailing list by Kai (Oct 10), Denny (Oct 12), and Jensen (Oct 13). 
May I kindly ask the authors of the document to address these comments 
ASAP and post a new version of the document?


Thanks,

Jan

Am 28.09.20 um 18:42 schrieb Jan Seedorf:

Dear all,

as discussed during the ALTO session at IETF-108, we are moving 
forward with all the remaining milestones.


Thus, this email starts a WGLC for 
draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, 
so from today, Monday, September 28, until Monday, Oktober 12, 2020.


We would like to have two individual reviews of this document as part 
of the WGLC. Please send us an email if you are willing review the 
draft as part of WGLC. We really need these reviews to make progress.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO@IETF-109

[Jan Seedorf]

Dear all,

ALTO has a slot at IETF 109.  We would like to devote the entire slot to 
the re-charter discussion that started in IETF 108. However, we would 
like to advise that the presentation for re-charter discussion be more 
focused in this iteration as compared to the previous one, where we had 
more than 11 presentations.


It will be helpful if the re-chartering team can cluster the different 
pieces of work now proceeding as individual drafts towards a small set 
of concrete work items/milestones.  Also, a proposed new charter would 
be very helpful.


Thus, the re-chartering team can use (perhaps no more than) half an hour 
to go through the drafts, then present a proposal for a new charter, and 
then we can open up the floor for general recharter discussion, so the 
majority of the time is spent soliciting, discussing, and shaping the 
new charter and subsequent deliverables.


 - Vijay & Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12

[Jan Seedorf]

Hi Jensen,

a third review is surely useful, so if you can find the time we would 
appreciate it.


Thanks,

Jan

Am 30.09.20 um 03:06 schrieb Jensen Zhang:

Hi Vijay,

I can also provide another review for performance-metrics. I see there 
have been already two reviewers. Do we still need one more?


Thanks,
Jensen


On Tue, Sep 29, 2020 at 2:53 PM Vijay Gurbani <mailto:vijay.gurb...@gmail.com>> wrote:


Dear Danny: Excellent, and thank you for your time on this.

We still need one more reviewer for performance-metrics and two
for path-vector.

All: Please step up.

Thank you.


On Tue, Sep 29, 2020 at 8:32 AM Danny Alex Lachos Perez
mailto:dlachos...@gmail.com>> wrote:

Hello Jan & Vijay

I will review the Performance Metrics document.

Bestregards,

Danny Lachos


On Mon, Sep 28, 2020 at 1:42 PM Jan Seedorf mailto:i...@j-f-s.de>> wrote:

Dear all,

as discussed during the ALTO session at IETF-108, we are
moving forward
with all the remaining milestones.

Thus, this email starts a WGLC for
draft-ietf-alto-performance-metrics-12. The WGLC will run
two weeks, so
from today, Monday, September 28, until Monday, Oktober
12, 2020.

We would like to have two individual reviews of this
document as part of
the WGLC. Please send us an email if you are willing
review the draft as
part of WGLC. We really need these reviews to make progress.

  - Vijay and Jan

___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] WGLC for draft-ietf-alto-path-vector-11

[Jan Seedorf]

Dear all,

as discussed during the ALTO session at IETF-108, we are moving forward 
with all the remaining milestones.


Thus, this email starts a WGLC for draft-ietf-alto-path-vector-11. The 
WGLC will run two weeks, so from today, Monday, September 28, until 
Monday, Oktober 12, 2020.


We would like to have two individual reviews of this document as part of 
the WGLC. Please send us an email if you are willing review the draft as 
part of WGLC. We really need these reviews to make progress.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] WGLC for draft-ietf-alto-performance-metrics-12

[Jan Seedorf]

Dear all,

as discussed during the ALTO session at IETF-108, we are moving forward 
with all the remaining milestones.


Thus, this email starts a WGLC for 
draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, so 
from today, Monday, September 28, until Monday, Oktober 12, 2020.


We would like to have two individual reviews of this document as part of 
the WGLC. Please send us an email if you are willing review the draft as 
part of WGLC. We really need these reviews to make progress.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Minutes from IETF-108

[Jan Seedorf]

Dear all,

please find below the minutes from the ALTO session at IETF-108 which I 
just uploaded to the datatracker. Please let us know any comments or 
corrections you might have.


A big thanks to Qiao and Sabine for taking the notes!

 - Jan & Vijay




- AGENDA & MATERIAL ---

IETF 108, Virtual Meeting
ALTO WG, Mon Jul 27, 2020 14:10 - 15:50

14:10 - 14:15   5"   Chair slides
14:16 - 14:26  10"   Unified Properties, Sabine Randriamasy [1]
14:27 - 14:35   8"   Performance metrics, Richard Yang [2]
14:36 - 14:41   5"   CDNI, Jensen Zhang [3]
14:42 - 14:52  10"   Path vector, Kai Gao [4]
14:53 - 15:50  57"   Recharter discussion

[1] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-12
[2] https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
[3] https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-12
[4] https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/

Slides
https://datatracker.ietf.org/meeting/108/session/alto

- ATTENDANCE: 40-43 people ---
Bluesheet: 
https://www.ietf.org/proceedings/108/bluesheets/bluesheets-108-alto-202007271410-00.txt 


WG Chairs: Vijay Gurbani, Jan Seedorf
Area Director: Martin Duke

Minute takers: Sabine Randriamasy, Qiao Xiang

- ACRONYMS AND NAMES USED IN THE MINUTES 
---

CX Chunshan Xiong
DL Danny Lachos
JS Jan Seedorf
JZ Jensen Zhang
KG Kai Gao
MD Martin Duke
RY Richard Yang
SR Sabine Randriamasy
VG Vijay Gurbani

APM     ALTO Performance Cost Metrics (WG draft)
CDNI    Content Delivery Network Interconnection (CDNI) Request Routing: 
CDNI
 Footprint and Capabilities Advertisement using 
ALTO (WG draft)

PV     Path Vector (WG draft)
UP     Unified Properties for the ALTO protocol  (WG draft)
EG     e.g.

- MINUTES ---

- 0. Chair slides

Overall document status: cost calendar and SSE are in RFC editor. CDNI 
has passed WGLC. Unified properties is in WGLC.


The focus of the WG is to finalize the charter items. Right now things 
are going well. unified properties is in WGLC, and the chairs things 
path vector and performance metrics are also ready for entering WGLC. 
However, due to their dependency on unified properties, the chairs and 
the AD decide to hold them from WGLC until unified properties passes WGLC.


In addition, this meeting will also discuss rechartering. The chairs are 
happy to see the discussion and energy on the mailing list for 
rechartering items.
VG on the ALTO rechartering disc kick-off. The goal is to get a sense, 
as meant in RFC2418, (see slide 7: does charter address relevant issues 
for the Internet community? Are goals specific and achievable (in 
reasonable time) ? Does the WG have the expertise ? ) Goal is not to 
take a re-charter decision during IETF 108 but open the discussion.  The 
proposed stuff should be achievable. So expertise and energy is needed in WG



- 1. Unified Properties:
Sabine introduces the key design update and text update in the draft. In 
particular, the definition of "defining information resource" is 
introduced. The draft is in WGLC until August 7.


Vijay: the draft is fairly mature.
Jan: people are encouraged to read the document and if there is any 
question, please send to auhors. SR adds 2 other drafts depend on UP so 
UP needs to be clear.



- 2. Performance Metrics:

Richard introduces the key design updates from v10 to v12 to address key 
comments from 107 meeting: (1) how to choose types of metrics => ALTO 
provides guidance, not measurement framework, and 4 types of guidance 
are chosen; (2) how to conform to rfc6390 => define metrics in the 
document by defining metric name, metric description, units of 
measurment and measurement points, and provide context information for 
coarse-grained information such as routing system information; (3) how 
to handle different statistics => provide complete statistic by adding 
stddev and stdvar and (4) how to convey freshness => use HTTP Last-Modified.


Vijay: after the minor edits suggested by the authors, this document is 
ready for WGLC after UP.



- 3. CDNI:

Jensen presents the key changes from v11 to v12: (1) generalize media 
types and attribute names to make FCI a special case, and (2) update 
sections related to unified properties, such as representing footprint 
objects as property map entities and representing CDNI capabilities as 
property map entity properties.


Vijay: this document also depends on unified properties.
No questions so this draft will move ahead.


- 4. Path vector:

Kai presents the updates and status of this draft. This draft is waiting 
to start WGLC, depending on unified properties. Key updates in v11 
includes text updates on the motivation example of flow scheduling, the 
discussion on e

Re: [alto] WGLC for draft-ietf-alto-unified-props-new-12

[Jan Seedorf]

Hi Richard,

sure, that suffices, great.

Thanks,

Jan

Am 24.07.20 um 14:40 schrieb Y. Richard Yang:

Hi Jan,

I remember that Danny and Luis will review the updated UP draft. Is 
this enough?


Richard

On Fri, Jul 24, 2020 at 8:36 AM Jan Seedorf <mailto:i...@j-f-s.de>> wrote:


Dear all,

we are still looking for individual reviewers for
draft-ietf-alto-unified-props-new-12 (see below). We will bring
this up
on Monday during the ALTO session, in hope of finding volunteers.

  - Jan

Am 17.07.20 um 19:01 schrieb Jan Seedorf:
> Dear all,
>
> after a discussion with Vijay on how to move forward with the
pending
> documents, we decided to start a WGLC for the unified properties
> document now. Thus, this email starts a WGLC for
> draft-ietf-alto-unified-props-new-12. The WGLC will run from today,
> Fri, July 17, 2020, to Fri, August 7, 2020.
>
> We would like to have two individual reviews of this document as
part
> of the WGLC. Please send us an email if you are willing review the
> draft as part of WGLC.
>
>  - Vijay and Jan
>
> ___
> alto mailing list
> alto@ietf.org <mailto:alto@ietf.org>
> https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto

--
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-unified-props-new-12

[Jan Seedorf]

Dear all,

we are still looking for individual reviewers for 
draft-ietf-alto-unified-props-new-12 (see below). We will bring this up 
on Monday during the ALTO session, in hope of finding volunteers.


 - Jan

Am 17.07.20 um 19:01 schrieb Jan Seedorf:

Dear all,

after a discussion with Vijay on how to move forward with the pending 
documents, we decided to start a WGLC for the unified properties 
document now. Thus, this email starts a WGLC for 
draft-ietf-alto-unified-props-new-12. The WGLC will run from today, 
Fri, July 17, 2020, to Fri, August 7, 2020.


We would like to have two individual reviews of this document as part 
of the WGLC. Please send us an email if you are willing review the 
draft as part of WGLC.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] WGLC for draft-ietf-alto-unified-props-new-12

[Jan Seedorf]

Dear all,

after a discussion with Vijay on how to move forward with the pending 
documents, we decided to start a WGLC for the unified properties 
document now. Thus, this email starts a WGLC for 
draft-ietf-alto-unified-props-new-12. The WGLC will run from today, Fri, 
July 17, 2020, to Fri, August 7, 2020.


We would like to have two individual reviews of this document as part of 
the WGLC. Please send us an email if you are willing review the draft as 
part of WGLC.


 - Vijay and Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO at IETF-108: Finishing the current milestones and discussion on re-chartering the WG

[Jan Seedorf]

Dear all,

Martin (our new AD), Vijay and myself had some discussions on how to 
generally move forward with the WG and how to plan the IETF-108 ALTO 
session accordingly. We believe we should finalize the remaining 
milestones (see https://tools.ietf.org/wg/alto/charters) by or at the 
latest during the IETF-108 ALTO session. Our understanding is that 
during the weekly meetings the remaining docs are making good progress 
towards such finalization, so this goal should be realistic.


After IETF-108, we can either (gradually) close the WG or re-charter. In 
both cases, there should be no need for an ALTO session at IETF meetings 
to discuss progress on the currently chartered milestones. If still 
needed, such progress can happen on the mailing list.


Accordingly, we plan the 100 minute online/virtual ALTO session at 
IETF-108 as follows:


a) 40 minutes for presentations on the drafts that address the remaining 
milestones, after which we hopefully can move all of them to WGLC (if 
not already done before, e.g. as with the ALTO-CDNI draft which is past 
WGLC)


b) 60 minutes for presentations and discussions on potentially 
re-chartering the WG (as opposed to closing down the WG).


We are soliciting presentations on re-charter proposals and thoughts. 
There will be no time allocated for presentations on drafts that are not 
currently a WG item.


Needless to say, any thoughts on re-chartering are welcome on the 
mailing list at any time. We hope for a fruitful discussion at the 
online/virtual ALTO session at IETF-108 that will hopefully end up in 
some form of consensus on how to move forward with the WG.


 - Vijay & Jan


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Agenda requests for IETF 107

[Jan Seedorf]

Dear all,

please send agenda requests for IETF-107 to Vijay and me.

Thanks,

Jan

On 28.02.20 23:35, "IETF Secretariat" wrote:

Dear Vijay Gurbani,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.


 alto Session 1 (2:00 requested)
 Thursday, 26 March 2020, Afternoon Session I 1330-1530
 Room Name: Georgia B size: 150
 -


iCalendar: https://datatracker.ietf.org/meeting/107/sessions/alto.ics

Request Information:


-
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 25
Conflicts to Avoid:
  Chair Conflict: icnrg tsvarea panrg maprg

  Key Participant Conflict: nmrg


People who must be present:
   Vijay K. Gurbani
   Jan Seedorf
   Mirja Kuehlewind

Resources Requested:

Special Requests:
   
-



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [CDNi] [E] WGLC for draft-ietf-alto-cdni-request-routing-alto-09

[Jan Seedorf]

Dear Sanjay,

thank you very much for reading the draft carefully and for your 
comments! We will go through them and address them.


 - Jan (and co-authors)

On 20.02.20 00:12, sanjay.mishra=40verizon@dmarc.ietf.org wrote:


I have review draft-ietf-alto-cdni-request-routing-alto-09 and don’t 
have any issues except some minor suggestions and nits.


*Sec 1 Introduction:*

1.If by using “functionalities” below is meant to reference the two 
RFC (RFC 7975 & RFC 8008), semantically, it may be better to state 
that the request routing interface is covered in two separate RFCs and 
reference the two RFC by name and number.


a.Correspondingly, the request routing interface is broadly divided 
into two functionalities: (1) CDNI Footprint & Capabilities 
Advertisement interface (FCI), and (2) CDNI Request Routing 
Redirection interface (RI).


2.(replace is -> are)

a.A protocol to transport and update such objects between a uCDN and a 
dCDN, however, is not defined


3.(delete “some”)

b.In this way, a uCDN can effectively fetch capabilities of some 
footprints in which it is interested


4.(add “as defined” instead of “defined” in two places in the sentence 
starting as below)


c.Throughout this document, we use the terminologies for CDNI defined…

*Section 2.1:*

5.(replace “For a detailed discussions” with “For detailed information…” )

d.For a detailed discussion, the reader is referred to the RFCs.

6.Remove extra sub bullet at the end of section 2.1 since there is no 
text (check the document for other instances of bullet but no text).


*Section 2.2:*

7.Remove reference to I-D.jenkins-alto-cdn-use-cases

8.Replace (“Identifications -> Identification): Security: 
Identifications between uCDNs and dCDNs are extremely important


9.Can an example be added of what unexpected cases authors envision?

a.Error-handling: The ALTO protocol has undergone extensive revisions 
in order to provide sophisticated error-handling, in particular 
regarding unexpected cases


*Section 6:*

10.Re-word (“First, we describe how to represent”)

a.We firstly describe how to represent

11.Replace (“And then” with “Second”)

*Section 8:*

12.Add a colon  after follows

a.included as follows.

13.Needs some rewording for the sentence below:

a.For availability of ALTO services, an attacker may get the potential 
huge full CDNI


Thanks

Sanjay

*From:*CDNi [mailto:cdni-boun...@ietf.org] *On Behalf Of *Vijay Gurbani
*Sent:* Monday, February 3, 2020 10:08 AM
*To:* IETF ALTO ; c...@ietf.org
*Subject:* [E] [CDNi] WGLC for 
draft-ietf-alto-cdni-request-routing-alto-09


All: Jan and I will like to start WGLC for
draft-ietf-cdni-request-routing-alto-09.  The WGLC period will run 
from Mon,

Feb 3 2020 to Wed, Feb 19 2020.

This email is also being cross-posted to the CDNI working group.

We will like to have one WG list member from ALTO and one WG list 
member from


CDNI review this draft in depth.  Please send Jan and me an email if 
you are willing


review the draft as part of WGLC.

In addition, we will like general reviews of the draft from both ALTO 
and CDNI WGs.


Thank you.


___
CDNi mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [CDNi] WGLC for draft-ietf-alto-cdni-request-routing-alto-09

[Jan Seedorf]

Dear Danny,

thank you very much for reading the draft carefully and for your 
comments! We will go through them and address them.


 - Jan (and co-authors)

On 17.02.20 18:19, Danny Alex Lachos Perez wrote:

Dear authors,

I have performed a review of this draft (-09).
My comments are below:

1) Section 2.2

"Application-Layer Traffic Optimization (ALTO) [RFC7285  
] is an
approach for guiding the resource provider selection process in
distributed applications that can choose among several candidate
resources providers to retrieve a given resource.  By conveying
network layer (topology) information, an ALTO server can provide
important information to "guide" the resource provider selection
process in distributed applications."

 The two paragraphs are very similar in content, consider merging.
E.g.:
"Application-Layer Traffic Optimization (ALTO) [RFC7285] is an
approach for conveying network layer (topology) information to
"guide" the resource provider selection process in distributed
applications."

2) Section 2.2

"Recently, however, ALTO is
also being considered for improving the request routing in CDNs
[I-D.jenkins-alto-cdn-use-cases  
]."

The reference dates from 2012 and it is an expired draft


3) Section 2.2

   "This would enable a uCDN to

   determine if a given dCDN actually has the capabilities for a
   given request with respect to the type of content requested."

Wordy sentence, consider rewriting: e.g., "This would enable a
uCDN to determine if a dCDN actually has the capabilities for a
given type of content request."


4) Section 2.1

"  related to CDNI Metadata.

o"

Remove last bullet (there is no text)


5) Introduction

"instead of getting the full resource which can be huge.Section 6  
"

Consider adding a comma: "instead of getting the full resource*,*
which can be huge. Section 6"


6) Introduction

"Section 7  
  
andSection 8  
  
respectively."

Consider adding a comma: "Section 7 and Section 8, respectively."


7) Section 2.2

"   in particular for an FCI protocol:

o"

Remove bullet (there is no text)


8) Section 4.2.4

"In this example, the ALTO client is interested in changes of "my-
cdnifci-with-pid-footprints".  Considering two changes, the first one"

Consider rewriting: "In this example, the ALTO client is
interested in two changes of "my- cdnifci-with-pid-footprints".
The first one"

9) Section 2.2

"design of ALTO supports server pushed incremental updates

   [I-D.ietf-alto-incr-update-sse  
].."

Consider updating the reference

sse-17 -> sse-19


10) Section 2.2

"  ALTO Path
   Vector Extension [I-D.ietf-alto-path-vector  
]
 is designed to allow"

Consider updating the reference

vector-08 -> vector-09


11) Section 2.2

"footprint by a dCDN, in particular
   if such a footprint is being"

Consider adding a comma: "... in particular*,* if such ..."


12) Section 2.2

"would enable a dCDN to directly inform a uCDN about such changes."

Consider rewriting: "to directly inform a uCDN about such changes"
-> "to inform a uCDN about such changes directly"


13) Section 3.6

"value and footprints, where footprints are defined in"

Consider adding a comma: "... value, and footprints ..."


14) Section 5.6

"an full CDNI FCI resource (SeeSection 3.6  
.)"

"an full" -> a full


15) Section 6

"CDNI capabilities, the most natrual way to satisfy this requirement"

"natrual" -> "natural"


16) Section 6

"   is to use the ALTO property map defined in
[I-D.ietf-alto-unified-props-new  
]."

Consider updating the reference

new-09 -> new-10


17) Section 6.1.1.2

"The entity identifiers of entities in an asn domain is encoded as a"

Consider changing the verb form: "The entity identifiers of
entities in an asn domain *are* encoded..."


18) Section 6.1.2.2

"The entity identifiers of entities in a countrycode domain is encoded"

Consider changing the verb

[alto] Finalizing draft-ietf-alto-cdni-request-routing-alto

[Jan Seedorf]

Dear CDNI chairs and CDNI WG,

the ALTO WG is finalizing "Content Delivery Network Interconnection 
(CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement 
using ALTO" (draft-ietf-alto-cdni-request-routing-alto-08). For the WGLC 
we are about to issue, we would like to have one individual review from 
a CDNI expert (the other one coming from the ALTO WG). Can you please 
name/choose/recommend a CDNI expert that can provide an individual 
review for the draft? We (ALTO chairs) would then start the WGLC ...


Thanks,

Kind regards,

Jan


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Finalizing the ALTO CDNI-FCI Document

[Jan Seedorf]

Dear CDNI folks,

some time ago it was agreed (in the CDNI WG) that the transport of CDNI 
FCI objects defined in RFC8008/8006 will be done via a new ALTO service. 
The corresponding work was thus transferred to the ALTO WG. We are now 
finalizing this document and would like to have CDNI experts to have a look:


https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-06

The FCI JSON objects and their semantics from RFC8008/8006 have not 
changed; the draft cited above defines a new ALTO service to transport 
such objects.


We plan to issue a WGLC on this document soon, so please have a look and 
let us know any comments you might have. We would also appreciate if 
during the upcoming  2-week WGLC we could have one individual reviewer 
from the CDNI WG (Kevin?).


Let us (the authors and the ALTO WG) know if you have any questions or 
comments.


 - Jan

--

Prof. Dr. Jan Seedorf
Chief Information Security Officer (CISO)
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Progress on CDNI FCI Draft

[Jan Seedorf]

Dear Jensen,

it is too late for such drastic design changes. What has long been 
agreed in the CDNI WG is that RFC8006/8008 define the JSON format for 
CDNI which suit the CDNI requirements. These had been discussed in CDNI 
for many years at many meetings. So that is fixed. What we need to do in 
ALTO is design an ALTO-based transport for these JSON objects, i.e. 
fefining a new ALTO service for the JSON objects specified in RFC8006/8008.


 - Jan

On 03.07.19 15:30, Jensen Zhang wrote:

Hi authors of draft-ietf-cdni-request-routing-alto,

Do we have any updates on the CDNI FCI document since IETF 104? 
Considering the CDNI FCI is an important use case of ALTO and a 
potential use case of the unified properties, I would like to resume 
the discussion and make this work move forward.


I have the following questions to the current CDNI FCI document:

1. According to the discussion we did in IETF 104, the design of the 
original CDNI FCI encoding in RFC8006/8008 is not an object-map. So it 
does not match the Map service design in the ALTO framework. Do we 
still want to reuse the encoding, or design new encodings to match the 
ALTO Map service framework?
2. Do we strongly require a more general query service for CDNI FCI? 
And what kind of queries are really required? Could we have some use 
cases to motivate the requirements?


I would like to engage in the discussion and the document revision 
if possible. I am looking forward to receiving the feedback from 
coauthors and other WG members.


Thanks,
Jensen
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Fwd: Remote presentations at IETF105 - cutoff date July 20

[Jan Seedorf]

Dear all,

if you intend to present at IETF105 in ALTO remotely, please let us (the 
chairs) know soon, so that we can request a remote presentation for you 
(see below).


 - Jan



 Forwarded Message 
Subject:Remote presentations at IETF105 - cutoff date July 20
Date:   Tue, 2 Jul 2019 12:16:07 +0200
From:   Meetecho IETF support 
To: wgcha...@ietf.org



Dear chairs,

as usual, please book your remote *presentation* slots at IETF105 by 
filling out the following form:


https://ietf105.conf.meetecho.com/index.php/Remote_presentations

*The cutoff date is July 20, 2019.*

You can also check scheduled remote presentations here:

https://ietf105.conf.meetecho.com/list.php

Thanks,
the Meetecho team

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Minutes from ALTO Session at IETF104

[Jan Seedorf]

Dear all,

please find below the minutes from the ALTO session at IETF-104. Many 
thanks to Sabine and Krystof for taking the notes. I have just uploaded 
these minutes to the IETF datatracker. if you have any comments or 
corrections, please let us (the chairs) know.


 - Jan & Vijay

*

ALTO WG IETF 104
Prague, Czech Republic
March 26, 2019

Notetakers:
Sabine Randriamasy
Krystof Miziewicz

ACRONYMS
ACAL    ALTO Calendar
DL     Danny Lachos
DC    Dawn Chen
JS    Jan Seedorf
MK    Mirja K¸ehlewind
PV    Path Vector
RY    Richard Yang
SSE    Server Sent Events
TC    Tim Chown
UP    Unified Properties
VG    Vijay Gurbani

ml: mailing list
pls: please

=
TUESDAY 26 MARCH
=
-
ALTO WG : 16h10 - 18h10
-

agenda: https://datatracker.ietf.org/doc/agenda-104-alto/
slides: https://datatracker.ietf.org/meeting/104/session/alto
session recording: https://www.youtube.com/watch?v=6LRI0GjpqfA
bluesheets: 
https://datatracker.ietf.org/doc/bluesheets-104-alto-201903261610/

- 17 people in room
- 8 people on Meetecho
Session chaired by Jan Seedorf


= WG Chairs (presenting: Jan) =

WG progress is pretty good. Focus on WG docs to finalize.
No new WG items will be added until then.
After that, the WG probably needs to re-charter and find new chairs.
6 WG items are remaining.
Draft dependencies exist: between PV and UP.

Tim chown - JSIC: are there any implementations around ? is there a page 
listing them?

RY: we have an ALTO survey doc with list of deployments and implementations.
SR: for minutes takers asks people to articulate when giving their name 
and affiliation
RY: we have regular meetings with many people, core contributors and 
others interested in re-charter items.

Danny: We have a document on implementations.
Jan: recommends to and will circulate it on the mailing list.

= (presenting: Sabine) - 
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-11 =

- current draft is ver 11 ñ submitted Febí19
- last IESG review in Dec 2018 on version 9
- revision upon review in version 10, this presentation focuses on ver 10
- substantial changes in section 4.1.2: reorganized to clarify text.
- all addressed comments from IESG ware submitted to reviewer. All 
approved. We wait for ART area review feedback (discuss 1).
- Next: we will post revision asap adressing WG Chair review, thank you 
Vijay, and wait for AD feedback


Discussion:
- Mirja: thanks for all those edits. We will have to run another IETF 
last call and put on telechat. I would'nt expect any further comments. 
One quick question: if you use new JSON format would this update 
RFC7285? there was a question on mailing list. What was the decision?
- Jan: afaiu this doc recommends 8259, is up to the WG to update the 
core protocol because 7159 wasn't out there at that time. Sabine, did 
IESG say anything or you introduced on your own?
- SR this was recommended by an IESG reviewer. The WG discuss on whether 
was former WG document tied to other formats than UTF-8. We identified 
none.
- Jan: implementations on 7285 using UTF 8 do not violate the protocol. 
For implementations using this extension (acal) it is clever to use UTF8 
in their core protocol implem. We can stop this discuss because there 
will be another IESG feedback. We feel we are inline.
- Richard: the new JSON format issue is not just applicable to ALTO but 
also to the other docs  such as CDNI. UTF8 format relates to PID name 
encoding.

- Jan: I think we agree. It's not an issue. let's wait for IESG feedback.
- Mirja: then to be on the safe side, please add discussion in the 
document pointing that there are different JSON formats recommended in 
the ALTO WG documents. Would be good to clarify this and were done.
- Jan : Sabine pls note for next revision: the document not only 
requires new format but also explain that other docs may use other 
formats. Then we kick it back to IESG.
- Mirja: I'll put the new doc on the telechat. Maybe nobody will read so 
don't expect further comments.

- Jan: maybe send back to AD commenting on JSON and ask for feedback.
- Sabine: already done. We just wait for B. Campbell's feedback on how 
we adressed his discuss point.
- Jan comment on list by Vijay: everything good, there are just some 
minor comments. Please adress them and we kick it back to IESG.


=(presenting: Richard) - 
https://tools.ietf.org/wg/alto/draft-ietf-alto-incr-update-sse/ =

- draft converged after long work
- very important draft. used in ACal. But uses multipart responses, as 
does PV.

- We solved design issue on SSE for multipart responses.
- update 1: incremental encoding
- 2nd major change: compound resources
- Integrated handling of multipart, client ID becomes data-ID
- we seek WG feedback next week

Discussion
- JS: doc is ready now,

[alto] Fwd: URL for interim material

[Jan Seedorf]

https://datatracker.ietf.org/meeting/interim-2018-alto-01/session/alto



 Forwarded Message 
Subject:[alto] URL for interim material
Date:   Mon, 10 Dec 2018 23:38:26 -0600
From:   Vijay Gurbani 
To: alto@ietf.org



https://datatracker.ietf.org/meeting/interim-2018-alto-01/session/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Agenda for virtual interim on Dec 11, 13:00-15:00 CET

[Jan Seedorf]

Dear all,

here is the agenda for the interim tomorrow:

*** ALTO Virtual Interim Meeting ***
Dec 11, 2018
13:00-15:00 CET

13:00 Introduction and Agenda Bash (Chairs)
13:10 draft-ietf-alto-cost-calendar-09 (Sabine)
13:30 draft-ietf-alto-unified-props-new (Jensen)
13:45 draft-ietf-alto-incr-update-sse (Richard)
13:55 draft-ietf-alto-path-vector (Richard)
14:10 draft-ietf-alto-cdni-request-routing-alto (Jensen)
14:20 draft-zhang-alto-multipart (Jensen)
14:30 draft-xiang-alto-multidomain-analytics (Qiao)
14:40 draft-lachosrothenberg-alto-brokermdo (Danny)
14:50 Summary and Next Steps (chairs)

***

If we missed an agenda request, please let us know asap.

Looking forward to a productive meeting tomorrow,

Vijay & Jan


On 07.12.18 14:30, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:


Hi Jan and Vijay,

I would like to have a slot to present the IESG feedback and proposed 
updates on draft-ietf-alto-cost-calendar-09


- Name of presenter: S. Randriamasy

- Name of Internet-Draft: draft-ietf-alto-cost-calendar

- Link to Internet-Draft: 
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-09


- Length of presentation time: 20 mins

Thanks,

Sabine

*From:*alto  *On Behalf Of *Vijay Gurbani
*Sent:* Wednesday, December 05, 2018 5:16 PM
*To:* alto@ietf.org
*Subject:* [alto] Agenda requests for virtual interim

All: The ALTO WG virtual interim meeting is scheduled for Tue, Dec 11 
2018 @ 1300 CET / 0600 US Central.


Please send Jan and me an email if you would like to schedule an 
agenda slot.  Please provide the following information by end of the 
business day on Friday, Dec 7 2018.


- Name of presenter

- Name of Internet-Draft

- Link to Internet-Draft

- Length of presentation time

As usual, precedence will be given to those requests that advance the 
work of a WG milestone towards completion.


Thank you.


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Alvaro Retana's Discuss on draft-ietf-alto-cost-calendar-09: (with DISCUSS)

[Jan Seedorf]

Vijay, can you update the shepherd write up and re-run the wg last call with a 
note to the working group that this IPR exists?
As co-chair I agree: we need to inform the WG and re-do a WG last call, 
giving people the chance to comment if they think necessary


Sabine, maybe you can also address the other comments from the IESG in a new 
revision before we re-start WG last call, especially the use of examples IP 
addresses as flagged by Suresh and Adam, and use of https as flagged by Alissa 
and Adam. I think Ben’s discuss needs further discussion before we can update. 
Please reply to his email as well as soon as possible!

That is a good idea; Sabine, what do you think?

 - Jan

On 06.12.18 19:53, Mirja Kuehlewind (IETF) wrote:

Hi Sabine,

thanks for confirming this. I have set the „replaces“ field in the datatracker 
now correctly and the IPR shows up respectively.

Vijay, can you update the shepherd write up and re-run the wg last call with a 
note to the working group that this IPR exists?

Sabine, maybe you can also address the other comments from the IESG in a new 
revision before we re-start WG last call, especially the use of examples IP 
addresses as flagged by Suresh and Adam, and use of https as flagged by Alissa 
and Adam. I think Ben’s discuss needs further discussion before we can update. 
Please reply to his email as well as soon as possible!

Thanks!

Mirja




Am 06.12.2018 um 19:31 schrieb Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
:

Hello,
  
I confirm that the IPR attached to draft-randriamasy-alto-cost-calendar still applies to draft-ietf-alto-cost-calendar.

I also attach the IPR declaration that I sent on June 7th
Please let me know what I can do to help resolving this issue.
  
Sabine
  
  
  
From: Alvaro Retana 

Sent: Thursday, December 06, 2018 4:14 PM
To: Mirja Kuehlewind (IETF) 
Cc: alto-cha...@ietf.org; draft-ietf-alto-cost-calen...@ietf.org; The IESG 
; alto@ietf.org; Gurbani, Vijay (Nokia - US/Naperville) 

Subject: Re: [alto] Alvaro Retana's Discuss on 
draft-ietf-alto-cost-calendar-09: (with DISCUSS)
  
Perfect!
  
Thanks!
  
Alvaro.
  
On December 6, 2018 at 8:53:38 AM, Mirja Kuehlewind (IETF) (i...@kuehlewind.net) wrote:


I will check with authors and chairs, however it could also be the cause that 
the IPR was not applicable to the wg doc anymore, as there have been quite some 
changes to the -01 version of the draft (when the IPR was filed) and the 
adopted version.

If that is not the case, we will re-issue wg and IETF last call and bring it 
back.


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] AD review of draft-ietf-alto-xdom-disc

[Jan Seedorf]

Martin, Sebastian,

I suggest you get to the editorial comments from Mirja sometime soon, so 
we that a new version is published by the time this goes into the IESG 
call in December.


 - Jan


On 30.10.18 18:33, Mirja Kuehlewind (IETF) wrote:

Hi authors, hi shepherd,

thanks for the well-written document and write-up! I've reviewed the draft and 
would be ready to start IETF last call any time. However, I will not be able to 
join the next telechat on Nov 21 and therefore this doc has to wait for final 
approval for Dec 6 anyway. That means we have plenty of time to start IETF last 
call and I would prefer to start it after the meeting week! Let me know if 
there are any concerns about this time line!

While I think the document is ready, I of course still have a couple comments 
after my review. See below for my comments which are mostly editorial. Feel 
free to address them or not and update the doc before or after IETF last call 
accordingly. Just let me know what your plans are!

Thanks!
Mirja

———
Review Comments:

1) There are a few abbreviations that are not spelled out at first occurrence 
(but later instead). Can you double-check this…?
(You can also check with the RFC Editor Abbreviations List:
https://www.rfc-editor.org/materials/abbrev.expansion.txt )

2) This part seems to be twice in the doc

sec 2: "For the remainder of the document, we use the notation:
IRD_URIS_X = XDOMDISC(X,"ALTO:https“)“

sec 3: "For the remainder of the document, we use the following notation for
calling the ALTO Cross-Domain Server Discovery Procedure:

   IRD_URIS_X = XDOMDISC(X,"ALTO:https“)“

I guess you can just remove it in sec 2.

3) sec 3: "These error
conditions have to be reported to the caller in an appropriate way.“
Would you be able to say more here?

4) sec 3.4: "If no IRD URI could be
found after looking up all domain names from the 3rd and 4th column,
the procedure terminates unsuccessfully, without producing a result.“
What does this mean for the caller? Or should an empty result rather be 
returned?

5) section 4: in 4.3 and 4.4 the step to call the ALTO Cross-Domain Server 
Discovery Procedure and then query the IRD(s) are listed as explicit step while 
in section 4.1. and 4.2 the same (?) steps are described in text. The way this 
is represented is a bit confusing. Also given these two first steps are always 
the same, is it really necessary to describe them separately in each 
subsection? To be honest, the way it is currently presented I’m a bit confused 
where the differences are…

6) Appendix A and B: Thanks for moving this part in the appendix. It is 
absolutely appropriate to have any such information in the appendix. However, 
please reconsider before final publication if all of this information actually 
has an achievable value or if some maybe can be removed before final 
publication. Also for appendix A please consider renaming it.

7) In appendix maybe replace "sk@labpc12“ with something more neutral e.g. 
„user1“…

   





___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-xdom-disc-03

[Jan Seedorf]

Jan Seedorf has requested publication of draft-ietf-alto-xdom-disc-03 as 
Proposed Standard on behalf of the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Minutes for IETF-101 Session uploaded to datatracker

[Jan Seedorf]

Hi all,

the subject line says it all. Please let us know if you spot anything or 
think something needs to be changed.


 - Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] SSE final touches

[Jan Seedorf]

Hi Richard,

great, thanks, as chair I support that decision in the light of 
finishing some charter items soon.


 - Jan


On 18.03.18 18:16, Y. Richard Yang wrote:

Jan,

The authors had a very extensive discussion again. We have decided to 
support only single-object ALTO resources, and leave multipart, which 
can be a nice feature to support composition without the need of 
accumulating all objects into a single object, as future work. We 
edited a few sentences to make clear.


Thanks a lot for the guidance!
Richard

On Sun, Mar 18, 2018 at 5:55 AM, Jan Seedorf <mailto:i...@j-f-s.de>> wrote:


Hi Richard,



2. One next step we are considering is the support of multipart
update. The sever may send a multipart message consisting of
multiple objects say A, B, ... each of which is a top level JSON
object.. Both merge patch and JSON patch support only a single
object and hence cannot apply if we want incremental updates.
Hence, if we want incremental updates, we need to provide an
individual client-id for each part of a multipart content.


what is the motivation behind the multipart update? Sure it is a
nice feature, but as you know, we are trying to finalise SSE asap.
So we would only like to introduce new feature at this time if
they are absolutely needed.

 - Jan


On 17.03.18 14:07, Y. Richard Yang wrote:

Dear all,

As we finalizing all aspects of SSE, two issues need some
discussions. Quick updates, without delaying the progress, can
produce a higher quality  document.

1. It is the notification-of-remove response issue. It is already
being started in an earlier thread. Any opinions will be appreciated.


Another alternative design is that we require that each potential
multipart service also allow individual transmissions. This is
the write up in the current version. Any quick discussions will
be great.

See you in London.
Richard
-- 
Richard



___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto
<https://www.ietf.org/mailman/listinfo/alto>



___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto
<https://www.ietf.org/mailman/listinfo/alto>




--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |
 =


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] SSE final touches

[Jan Seedorf]

Hi Richard,



2. One next step we are considering is the support of multipart 
update. The sever may send a multipart message consisting of multiple 
objects say A, B, ... each of which is a top level JSON object.. Both 
merge patch and JSON patch support only a single object and hence 
cannot apply if we want incremental updates. Hence, if we want 
incremental updates, we need to provide an individual client-id for 
each part of a multipart content.


what is the motivation behind the multipart update? Sure it is a nice 
feature, but as you know, we are trying to finalise SSE asap. So we 
would only like to introduce new feature at this time if they are 
absolutely needed.


 - Jan


On 17.03.18 14:07, Y. Richard Yang wrote:

Dear all,

As we finalizing all aspects of SSE, two issues need some discussions. 
Quick updates, without delaying the progress, can produce a higher 
quality  document.


1. It is the notification-of-remove response issue. It is already 
being started in an earlier thread. Any opinions will be appreciated.



Another alternative design is that we require that each potential 
multipart service also allow individual transmissions. This is the 
write up in the current version. Any quick discussions will be great.


See you in London.
Richard
--
Richard


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-03.txt

[Jan Seedorf]

Hi Sabine,

thanks for your answer; yes, that answers my question. That means that 
we can move UP ahead and your cellular address draft may add such 
endpoints at a later point in time.


 - Jan


On 16.03.18 15:12, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:

Hi Jan,

The current option is to keep the cellular addresses in a separate draft. Upon discussion 
among its authors, the UP draft focuses on the introduction of a new service information 
resource which is the (Filtered) Property Map service, applied to "entities" 
that extend from Endpoints to PIDs, ANEs, Cells and other potential entities. So the UP 
draft would provide the framework to convey Property Maps and introduce new Entities.
  
The definition of specific entities such as cells and ANEs are respectively located in the "ALTO Cellular Addresses" and "Path Vector" drafts.

The impact of cellular addresses and the UP draft is that cells are both 
entities and endpoints, and this has raised the need to further harmonize the 
usage of ALTO Address Type and ALTO Domain Type registries. Specifications in 
this direction have been added in section if the UP draft section on IANA 
considerations.

Hope this answers your question,
Sabine
  


-Original Message-
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jan Seedorf
Sent: Thursday, March 15, 2018 11:28 PM
To: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-03.txt

Authors,

can you please update the WG regarding the following:


I am taking a look again at the possibility of integrating cellular
into UP quickly. An alternative is that we get it done shortly, in the
next couple days.

If this is the approach, Sabine is a great person to work together.
Make sense, Sabine?

So, has this been done for UP-03, or are we moving UP and path vector ahead and 
will add cellular addresses later on?

   - Jan


On 05.03.18 18:36, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

  Title   : Unified Properties for the ALTO Protocol
  Authors : Wendy Roome
Shiwei Dawn Chen
Sabine Randriamasy
Y. Richard Yang
Jingxuan Jensen Zhang
Filename: draft-ietf-alto-unified-props-new-03.txt
Pages   : 27
Date: 2018-03-05

Abstract:
 This document extends the Application-Layer Traffic Optimization
 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
 properties" to other entity domains, and by presenting those
 properties as maps, similar to the network and cost maps in ALTO.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-03
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-ne
w-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-03


Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-03.txt

[Jan Seedorf]

Authors,

can you please update the WG regarding the following:

I am taking a look again at the possibility of integrating cellular 
into UP quickly. An alternative is that we get it done shortly, in the 
next couple days.


If this is the approach, Sabine is a great person to work together. 
Make sense, Sabine?
So, has this been done for UP-03, or are we moving UP and path vector 
ahead and will add cellular addresses later on?


 - Jan


On 05.03.18 18:36, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

 Title   : Unified Properties for the ALTO Protocol
 Authors : Wendy Roome
   Shiwei Dawn Chen
   Sabine Randriamasy
   Y. Richard Yang
   Jingxuan Jensen Zhang
Filename: draft-ietf-alto-unified-props-new-03.txt
Pages   : 27
Date: 2018-03-05

Abstract:
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to other entity domains, and by presenting those
properties as maps, similar to the network and cost maps in ALTO.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-03
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Updated ALTO agenda

[Jan Seedorf]

Presenters:

please have a look at the agenda, it is really tight. We therefore 
strongly encourage you to plan accordingly and stick to your allocated 
time. As the agenda is so full and tight, we will have to cut each 
presentation after the allocated time has passed. So please focus on the 
main points!


Looking forward to seeing you all in London,

 - Jan


On 15.03.18 17:37, Vijay K. Gurbani wrote:

Folks: There has been a slight change in the agenda as we added a
chartered item (SSE) to the discussion.

Please take a look at the updated agenda at

https://datatracker.ietf.org/meeting/101/materials/agenda-101-alto.txt

It is a packed agenda, as usual; please do pay attention to the minutes
allocated to determine the right number of slides for presentation.

Thank you,

- vijay
--
Vijay K. Gurbani / vijay.gurb...@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Agenda requests for IETF 101 in London

[Jan Seedorf]

Dear all,

please let us (the chairs) know if you want to present during the ALTO 
session at IETF-101 in London.


We really want to make progress with the milestones, so clear preference 
in the agenda will be given to documents that address the milestones.


We hope to see many of you in London,

Vijay & Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Virtual Interim Meeting (DEC 4th, 2017, 13:00 CET): Call for agenda items

[Jan Seedorf]

Dear all,

the ALTO WG will have an ALTO virtual meeting on:

*** Dec 4, 2017 @ 1300 CET ***

WebEx Details will follow.

Please let us know if you intend to present something, i.e. want agenda 
time. We will then prepare an agenda accordingly.


    - Vijay & Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Date/time for ALTO Virtual Interim

[Jan Seedorf]

Hi all,

according to the doodle, we will hold the ALTO Virtual Interim Meeting 
*** DEC 4th, 2017, 13:00-15:00 CET time ***


Please mark your calendars, more details will follow,

 - Vijay & Jan


On 13.10.17 20:38, Jan Seedorf wrote:

Hi all,

Vijay and I have discussed possible dates for an ALTO Virtual Interim 
Meeting in December, as we will not have an ALTO session at IETF-100 
in Singapore. I have set up a doodle with 2 possible options: Monday 
DEC 4th or Monday DEC 18; time will be 07:00-09:00 Chicago time = 
13:00-15:00 CET = evening time in Asia. Please vote so that we can 
decide on a date:


https://doodle.com/poll/mryzspqdf3gkrkt2

 - Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Doodle for ALTO Virtual Interim

[Jan Seedorf]

Hi all,

Vijay and I have discussed possible dates for an ALTO Virtual Interim 
Meeting in December, as we will not have an ALTO session at IETF-100 in 
Singapore. I have set up a doodle with 2 possible options: Monday DEC 
4th or Monday DEC 18; time will be 07:00-09:00 Chicago time = 
13:00-15:00 CET = evening time in Asia. Please vote so that we can 
decide on a date:


https://doodle.com/poll/mryzspqdf3gkrkt2

 - Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO minutes from IETF99 meeting

[Jan Seedorf]

Hi all,

since there were no comments, I have just uploaded the minutes to the 
datatracker.


 - Jan


On 07.08.17 13:00, Jan Seedorf wrote:

Dear all,

please find attached the minutes from the ALTO session at IETF99. 
Please let Vijay and myself have any comments/corrections within a week.


Many thanks to our note-takers Lyle and Sabine!

 - Jan

***

IETF 99, July 16-21, 2017. Prague, Czech Republic
ALTO WG Meeting, Thu Jul 20, 2017 1330-1530 Karlin III
Notetakers: Lyle Bertz, Sabine Randriamasy

1330 - 1340 10' Agenda bash and WG update (Chairs)
- Focus is to finish chartered items so the agenda is based on this 
(charter & milestone items are first; new topics are best effort)

- Goal is to finish milestones @ IETF-101
- Richard : Finish means?
Jan: If something is close to WGLC that should work; in 
principal finish means WGLC

- Last meeting: adopted path vector, unified prop, cdni
- milestones: Multi-Cost OK
- ALTO performance metrics needs more work (review)
- Props, Path Vector & CDNI need more work
- Other business?
- Richard:
- What is the timing for the next wg meeting if not meeting @ 
IETF 100?

- Jan: Timeframe is around Singapore
- AD: Clarification that meeting should not be at the time of 
IETF but closer to IETF 100

- Workshop is mid August in Los Angeles with LHC and other teams.

1340 - 1355 15' ALTO cost calendar, S. Randriamasy
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-02
- Reviewed all updates
- Discussion Items
- - RY several time granularities. Client can aggregate itself ?
=> SR: yes the server should provide finest granularity.
(TODO: the client SHOULD interpret the time interval 
size as the finest available from server).

- Richard / Sabine agree to move ahead on granularity response
- Sabine - The ALTO server provides the finest grain value for 
the time-interval
- Jan: After issues herein are closed does the team agree this should 
WGLC (hum)
- Result: No hums against moving it to WGLC once issues/open 
items are resolved

- Please make the resolutions on this on the list

1355 - 1410 15' ALTO cost context, S. Randriamasy
https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-02
- Reviewed Concepts and Updates per WG feedback
- Questions:
- Dawn - One suggestion is to make suggestion to specifiy the 
order of the response (has this been considered)?
- Different options were discussed. Will continute to mailing 
list.

- Would adding context to the cost add extra privacy concerns?
- This should be discussed in the document.
- Richard - point out that this is part of a more generalized 
issue of a type system in ALTO

- Type system was urged to be a future dicussion on this matter
- Richard: we need reconsider cost type design (type, mode, 
where fit context?)

- Seb: IANA considerations ?
==> SR yes we need look at other IETF Work and consider 
IANA registration.
- For now, chair ask is to move ahead but since it is not part of the 
milestones we will lead


1410 - 1425 15' ALTO incremental updates, R. Yang
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
- Overview of changes
- Does WG believe this is ready for WGLC after items are completed (hum)?
- No reaction either way
- Sabine - Main task is complete but needs work to specify who is 
sending a SSE and for what reason
- Suggestion is that we can make the Client/Server roles more 
explicit
- JS: JSON patch important for CDNI. WG seems now more active on that 
one.

- SR: needs clarification on who requires what for what
- RY: yes we will need to clarify that


1425 - 1435 10' CDN Footprints and Capability Advertisements, R. Yang
https://www.ietf.org/id/draft-seedorf-cdni-request-routing-alto-10.txt
   (This is a WG draft; needs to be resubmitted with the correct 
name.)

- Jan presenting
- Advanced design is being looked at but the focus is the basic design
- Richard - Discussion wrt the envelope name
- outcome is to use somehting like "cdni/fci"

1435 - 1450 15' ALTO path vector, D. Chan
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
- Discussed 3 remaining design issues
- Point raised about why this technique for MIME is not used in SSE
- Privacy implications exist for cross product query but PID flows don't

1450 - 1455 05' Extensible property maps for ALTO, D. Chan
https://datatracker.ietf.org/doc/draft-roome-alto-unified-props-new/
   (This is a WG draft; needs to be resubmitted with the correct 
name.)

-  With no time left, discussion will be deferred to the list
-  Jan: Please don't add use cases every 2 months or it will never get 
done


1455 - 1500 05' ALTO cross-domain server discovery, S. Kiesel
   https://datatracker.ietf.org/doc/draft-ietf-a

[alto] ALTO minutes from IETF99 meeting

[Jan Seedorf]

Dear all,

please find attached the minutes from the ALTO session at IETF99. Please 
let Vijay and myself have any comments/corrections within a week.


Many thanks to our note-takers Lyle and Sabine!

 - Jan

***

IETF 99, July 16-21, 2017. Prague, Czech Republic
ALTO WG Meeting, Thu Jul 20, 2017 1330-1530 Karlin III
Notetakers: Lyle Bertz, Sabine Randriamasy

1330 - 1340 10' Agenda bash and WG update (Chairs)
- Focus is to finish chartered items so the agenda is based on this 
(charter & milestone items are first; new topics are best effort)

- Goal is to finish milestones @ IETF-101
- Richard : Finish means?
Jan: If something is close to WGLC that should work; in 
principal finish means WGLC

- Last meeting: adopted path vector, unified prop, cdni
- milestones: Multi-Cost OK
- ALTO performance metrics needs more work (review)
- Props, Path Vector & CDNI need more work
- Other business?
- Richard:
- What is the timing for the next wg meeting if not meeting @ 
IETF 100?

- Jan: Timeframe is around Singapore
- AD: Clarification that meeting should not be at the time of 
IETF but closer to IETF 100

- Workshop is mid August in Los Angeles with LHC and other teams.

1340 - 1355 15' ALTO cost calendar, S. Randriamasy
   https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-02
- Reviewed all updates
- Discussion Items
- - RY several time granularities. Client can aggregate itself ?
=> SR: yes the server should provide finest granularity.
(TODO: the client SHOULD interpret the time interval 
size as the finest available from server).

- Richard / Sabine agree to move ahead on granularity response
- Sabine - The ALTO server provides the finest grain value for 
the time-interval
- Jan: After issues herein are closed does the team agree this should 
WGLC (hum)
- Result: No hums against moving it to WGLC once issues/open 
items are resolved

- Please make the resolutions on this on the list

1355 - 1410 15' ALTO cost context, S. Randriamasy
   https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-02
- Reviewed Concepts and Updates per WG feedback
- Questions:
- Dawn - One suggestion is to make suggestion to specifiy the 
order of the response (has this been considered)?

- Different options were discussed. Will continute to mailing list.
- Would adding context to the cost add extra privacy concerns?
- This should be discussed in the document.
- Richard - point out that this is part of a more generalized 
issue of a type system in ALTO

- Type system was urged to be a future dicussion on this matter
- Richard: we need reconsider cost type design (type, mode, 
where fit context?)

- Seb: IANA considerations ?
==> SR yes we need look at other IETF Work and consider 
IANA registration.
- For now, chair ask is to move ahead but since it is not part of the 
milestones we will lead


1410 - 1425 15' ALTO incremental updates, R. Yang
   https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
- Overview of changes
- Does WG believe this is ready for WGLC after items are completed (hum)?
- No reaction either way
- Sabine - Main task is complete but needs work to specify who is 
sending a SSE and for what reason
- Suggestion is that we can make the Client/Server roles more 
explicit

- JS: JSON patch important for CDNI. WG seems now more active on that one.
- SR: needs clarification on who requires what for what
- RY: yes we will need to clarify that


1425 - 1435 10' CDN Footprints and Capability Advertisements, R. Yang
   https://www.ietf.org/id/draft-seedorf-cdni-request-routing-alto-10.txt
   (This is a WG draft; needs to be resubmitted with the correct name.)
- Jan presenting
- Advanced design is being looked at but the focus is the basic design
- Richard - Discussion wrt the envelope name
- outcome is to use somehting like "cdni/fci"

1435 - 1450 15' ALTO path vector, D. Chan
   https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
- Discussed 3 remaining design issues
- Point raised about why this technique for MIME is not used in SSE
- Privacy implications exist for cross product query but PID flows don't

1450 - 1455 05' Extensible property maps for ALTO, D. Chan
   https://datatracker.ietf.org/doc/draft-roome-alto-unified-props-new/
   (This is a WG draft; needs to be resubmitted with the correct name.)
-  With no time left, discussion will be deferred to the list
-  Jan: Please don't add use cases every 2 months or it will never get done

1455 - 1500 05' ALTO cross-domain server discovery, S. Kiesel
   https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/
-  Richard - Document is useful but if we can carve out the principal it 
would be helpful, can you come up with more clear principles?

-  JS: seb said will look at it.
-  

Re: [alto] fci alto transport design discussion

[Jan Seedorf]

Hi Richard and all,

looking at RFC8008, its states that "FCI objects are composed of a 
dictionary of (key,value) pairs where the keys are the property names 
and the values are the associated property values.", meaning that the 
"capability-value" is a key. However, I did not find anything on 
multiple "capability-type" entries, and what to do when they are 
conflicting. From a CDNI perspective, it should certainly be possible to 
have something like in your example below: support http1.1 for footprint 
a and support http1.0 for footprint b.


I am for option 2) below, that is allow multiple entries with the same 
capability type.


The FCI use case may argue that we extend the incremental update w/ 
JSON Patch, to better handle arrays, right away.
Indeed. Do you want to choose one of the two (JSON Patch vs. JSON Merge 
Patch) or do you think of making JSON Merge Patch mandatory and JSON 
Patch optional and then we say in the ALTO FCI service specification 
that this one demands JSON Patch (as pecified in the ALTO incr. updates)?


 - Jan


On 03.07.17 13:59, Y. Richard Yang wrote:

Hi Jan, Jon, Kevin, all,

As we are working on the design, a key issue that we are trying to 
understand is the conflict resolution of the capabilities in the 
"capabilities" list [RFC8008]. Consider


   {
 "capabilities": [
   {
 "capability-type": "FCI.DeliveryProtocol",
 "capability-value": {
   "delivery-protocols": [
 "http/1.1",
   ]
 },
 "footprints": [
   
 ]
   },
   {
 "capability-type": "FCI.DeliveryProtocol",
 "capability-value": {
   "delivery-protocols": [
 "http/1.0",
   ]
 },
 "footprints": [
   
 ]
   }
 ]
   }

What if the footprints in the two entries have overlap? I see two 
options:
(1) Enforce that each capability-type has a single entry; that is, 
make capability-type a key;
(2) Allow multiple entries with the same capability-type, and the 
search is ordered by the array; that is, the result is the first 
matching footprints.


I assume that (2) is more flexible. An issue, however, is that it 
makes incremental updates harder. In other words, this issue will 
determine whether we should integrate JSON Patch. The current alto 
incremental updates, based on SSE and JSON Merge Patch, is pretty 
useful. The FCI use case may argue that we extend the incremental 
update w/ JSON Patch, to better handle arrays, right away.


Any clarification, comments and suggestions will be great.

Richard



--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Session Requests for IETF 99

[Jan Seedorf]

Dear all,

please let Vijay and myself know if you intend to present during the 
ALTO session at IETF-99 (details see below). Please let us know title, 
presenter, time needed, and respective draft name.


Hope to see all of you in Prague,

 - Jan


On 24.06.17 02:07, "IETF Secretariat" wrote:

Dear Vijay Gurbani,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

alto Session 1 (2:30:00)
 Thursday, Afternoon Session I 1330-1530
 Room Name: Karlin III size: 60
 -
 



Request Information:


-
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 20
Conflicts to Avoid:
  First Priority: tsvarea tsvwg tcpm i2rs nvo3 supa netmod netconf cdni ippm 
nfvrg
  Second Priority: dispatch rtcweb sipcore lmap



People who must be present:
   Vijay K. Gurbani
   Jan Seedorf
   Mirja Kuehlewind

Resources Requested:

Special Requests:
   
-


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Adding a milestone to ALTO regarding the CDNI FCI interface

[Jan Seedorf]

Dear all,

during the ALTO session at IETF-96 (the last F2F ALTO session), I 
presented on the CDNI-FCI interface and that it will be based on ALTO. 
In the meantime, RFC 8008 is done (https://tools.ietf.org/html/rfc8008), 
which is defining the JSON object to be transported in the CDNI-FCI 
interface via a new ALTO service. During the session, there was 
agreement to add a new ALTO milestone for a document specifying the new 
ALTO service to transport the CDNI-FCI JSON objects. Check the notes 
from the session:


"The CDNI WG is using ALTO for FCI interface.  CDNI is about to be 
closed and thus the work on specification of the transport of an FCI as 
a JSON object using ALTO is proposed to be done in ALTO.  We will need 
to add a new milestone to do this as a new ALTO service.  No one 
objected to doing this work in ALTO.  The ALTO WG will check that the 
new CDNI ALTO service is compatible with generic extensions to the core 
ALTO protocol and will ratify the decision to add a new milestone for 
this this work on the ALTO mailing list."


I think we never ratified this decision on the mailing list.

Are there any objections to add a new milestone for a document 
specifying a new ALTO service to transport CDNI-FCI JSON objects (as 
defined in RFC8008)?


 - Jan

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Shepherd Write-up for draft-ietf-alto-multi-cost

[Jan Seedorf]

The downward ref issue has been clarified (thanks to Sabine for quick 
and proper checking), so I removed the sentence "RFC2119 is listed as a 
normative reference but not listed in the DOWNREF Registry" from the 
write-up. The document is now in state "Submitted to IESG for Publication".


 - Jan


On 22/02/2017 18:27, Jan Seedorf wrote:


Dear all,

I just uploaded the shepherd write-up for draft-ietf-alto-multi-cost 
to the datatracker (fyi below).


Authors: you still need to fix one downward ref (see below). Let me 
know when you intend to do this. Once this is done, I will set the 
status to "submit to IESG".


 - Jan


*1. Summary*

Jan Seedorf is the document shepherd for draft-ietf-alto-multi-cost. 
Mirja Kühlewind is the responsible Area Director.


The document itself has a long history, having started as a -00 
document in the ALTO WG as an individual draft in October 2010 
(author: Sabine Randriamasy).It transitioned to a WG document in May 
2015 (after the ALTO WG had been re-chartered to work on extensions to 
the original ALTO protocol as specified in RFC 7285) (authors: Sabine 
Randriamasy, Wendy Roome, Nico Schwan).


The ALTO protocol as specified in RFC 7285 allows to only query 
results for one single ALTO cost metric in a given ALTO request. 
draft-ietf-alto-multi-cost defines a “new service that allows a client 
to retrieve several cost metrics with one request, which is 
considerably moreefficient” [draft-ietf-alto-multi-cost-04]. This is 
clearly a very useful extension of the ALTO protocol and covered in 
the current ALTO charter.


The working group is targeting this document as Standards Track, which 
is appropriate as the document extends the ALTO protocol, specifying 
new formats for allowed client requests (in JSON).



*2. Review and Consensus*

The document has been presented at multiple IETF meetings and 
discussed on the mailing list. It is well-known in the ALTO WG and 
there is clear consensus to standardise the proposed ALTO extension. A 
WGLC was issued on July 4, 2016.During this WGLC a detailed review has 
been produced by Xin Wang, extensive additional comments were provided 
by Richard Yang and Hans Seidel. The comments raised have been 
addressed in the -03 version of draft-ietf-alto-multi-cost. Last 
outstanding comments have been finally addressed in the latest -04 
(September 2016) and -05 versions (February 2017).


In summary, there is clear support and consensus for 
draft-ietf-alto-multi-cost in the ALTO WG, and it provides a very 
useful extension to the base ALTO protocol. A WGLC has successfully 
been passed, and extensive reviews were provided by various members of 
the WG and have all been addressed.


*3. Intellectual Property*

The shepherd confirms that each author has stated to him that to the 
best of his/her (i.e. the author’s) knowledge, all IPR related to this 
document has been disclosed.


There have been two IPR disclosures on this document (see 
https://datatracker.ietf.org/ipr/2615/ and 
https://datatracker.ietf.org/ipr/1628/). Both these IPR disclosures 
have been posted on the ALTO mailing list. There was no discussion on 
these IPR statements.


*4. Other Points*

RFC2119 is listed as a normative reference but not listed in the 
DOWNREF Registry 
(http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry) 
<http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry%29>. 
The authors have been notified and will fix this issue.


This document does not introduce any IANA considerations and does not 
introduce any privacy or security issues that are not already present 
in the ALTO protocol




___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Shepherd Write-up for draft-ietf-alto-multi-cost

[Jan Seedorf]

Dear all,

I just uploaded the shepherd write-up for draft-ietf-alto-multi-cost to 
the datatracker (fyi below).


Authors: you still need to fix one downward ref (see below). Let me know 
when you intend to do this. Once this is done, I will set the status to 
"submit to IESG".


 - Jan


*1. Summary*

Jan Seedorf is the document shepherd for draft-ietf-alto-multi-cost. 
Mirja Kühlewind is the responsible Area Director.


The document itself has a long history, having started as a -00 document 
in the ALTO WG as an individual draft in October 2010 (author: Sabine 
Randriamasy).It transitioned to a WG document in May 2015 (after the 
ALTO WG had been re-chartered to work on extensions to the original ALTO 
protocol as specified in RFC 7285) (authors: Sabine Randriamasy, Wendy 
Roome, Nico Schwan).


The ALTO protocol as specified in RFC 7285 allows to only query results 
for one single ALTO cost metric in a given ALTO request. 
draft-ietf-alto-multi-cost defines a “new service that allows a client 
to retrieve several cost metrics with one request, which is considerably 
moreefficient” [draft-ietf-alto-multi-cost-04]. This is clearly a very 
useful extension of the ALTO protocol and covered in the current ALTO 
charter.


The working group is targeting this document as Standards Track, which 
is appropriate as the document extends the ALTO protocol, specifying new 
formats for allowed client requests (in JSON).



*2. Review and Consensus*

The document has been presented at multiple IETF meetings and discussed 
on the mailing list. It is well-known in the ALTO WG and there is clear 
consensus to standardise the proposed ALTO extension. A WGLC was issued 
on July 4, 2016.During this WGLC a detailed review has been produced by 
Xin Wang, extensive additional comments were provided by Richard Yang 
and Hans Seidel. The comments raised have been addressed in the -03 
version of draft-ietf-alto-multi-cost. Last outstanding comments have 
been finally addressed in the latest -04 (September 2016) and -05 
versions (February 2017).


In summary, there is clear support and consensus for 
draft-ietf-alto-multi-cost in the ALTO WG, and it provides a very useful 
extension to the base ALTO protocol. A WGLC has successfully been 
passed, and extensive reviews were provided by various members of the WG 
and have all been addressed.


*3. Intellectual Property*

The shepherd confirms that each author has stated to him that to the 
best of his/her (i.e. the author’s) knowledge, all IPR related to this 
document has been disclosed.


There have been two IPR disclosures on this document (see 
https://datatracker.ietf.org/ipr/2615/ and 
https://datatracker.ietf.org/ipr/1628/). Both these IPR disclosures have 
been posted on the ALTO mailing list. There was no discussion on these 
IPR statements.


*4. Other Points*

RFC2119 is listed as a normative reference but not listed in the DOWNREF 
Registry 
(http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry) 
<http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry%29>. 
The authors have been notified and will fix this issue.


This document does not introduce any IANA considerations and does not 
introduce any privacy or security issues that are not already present in 
the ALTO protocol


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Updated ALTO Milestones

[Jan Seedorf]

Dear Mirja,

the ALTO milestones are out-of-date. Attached is an updated list of the 
ALTO milestones that Vijay and I have prepared. Please have a look and 
let us know if you agree. If you would like detailed infos on the 
progress towards each charter item/milestone (for some we are at WGLC 
and for others we have mature WG items drafts) let us know. We will have 
an ALTO session in Chicago, where we hope to make further progress 
towards these charter items, so we think the milestones are actually 
realistic.


 - Jan


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


{\rtf1\adeflang1025\ansi\ansicpg1\uc1\adeff0\deff0\stshfdbch0\stshfloch31506\stshfhich31506\stshfbi31506\deflang2057\deflangfe2057\themelang1031\themelangfe0\themelangcs0{\fonttbl{\f0\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\f2\fbidi \fnil\fcharset0\fprq2{\*\panose 02070309020205020404}Courier New;}
{\f14\fbidi \fnil\fcharset2\fprq2{\*\panose 0500}Wingdings;}{\f34\fbidi \fnil\fcharset0\fprq2{\*\panose 02040503050406030204}Cambria Math;}{\f36\fbidi \fnil\fcharset0\fprq2{\*\panose 020f0502020204030204}Calibri;}
{\flomajor\f31500\fbidi \fnil\fcharset0\fprq2{\*\panose 020b0604020202020204}Arial;}{\fdbmajor\f31501\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}
{\fhimajor\f31502\fbidi \fnil\fcharset0\fprq2{\*\panose 020f0302020204030204}Calibri Light;}{\fbimajor\f31503\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}
{\flominor\f31504\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\fdbminor\f31505\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}
{\fhiminor\f31506\fbidi \fnil\fcharset0\fprq2{\*\panose 020f0502020204030204}Calibri;}{\fbiminor\f31507\fbidi \fnil\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\f45\fbidi \fnil\fcharset238\fprq2 Times New Roman CE;}
{\f46\fbidi \fnil\fcharset204\fprq2 Times New Roman Cyr;}{\f48\fbidi \fnil\fcharset161\fprq2 Times New Roman Greek;}{\f49\fbidi \fnil\fcharset162\fprq2 Times New Roman Tur;}{\f50\fbidi \fnil\fcharset177\fprq2 Times New Roman (Hebrew);}
{\f51\fbidi \fnil\fcharset178\fprq2 Times New Roman (Arabid);}{\f52\fbidi \fnil\fcharset186\fprq2 Times New Roman Baltic;}{\f53\fbidi \fnil\fcharset163\fprq2 Times New Roman (Vietnamese);}{\f65\fbidi \fnil\fcharset238\fprq2 Courier New CE;}
{\f66\fbidi \fnil\fcharset204\fprq2 Courier New Cyr;}{\f68\fbidi \fnil\fcharset161\fprq2 Courier New Greek;}{\f69\fbidi \fnil\fcharset162\fprq2 Courier New Tur;}{\f70\fbidi \fnil\fcharset177\fprq2 Courier New (Hebrew);}
{\f71\fbidi \fnil\fcharset178\fprq2 Courier New (Arabid);}{\f72\fbidi \fnil\fcharset186\fprq2 Courier New Baltic;}{\f73\fbidi \fnil\fcharset163\fprq2 Courier New (Vietnamese);}{\f385\fbidi \fnil\fcharset238\fprq2 Cambria Math CE;}
{\f386\fbidi \fnil\fcharset204\fprq2 Cambria Math Cyr;}{\f388\fbidi \fnil\fcharset161\fprq2 Cambria Math Greek;}{\f389\fbidi \fnil\fcharset162\fprq2 Cambria Math Tur;}{\f392\fbidi \fnil\fcharset186\fprq2 Cambria Math Baltic;}
{\f393\fbidi \fnil\fcharset163\fprq2 Cambria Math (Vietnamese);}{\f405\fbidi \fnil\fcharset238\fprq2 Calibri CE;}{\f406\fbidi \fnil\fcharset204\fprq2 Calibri Cyr;}{\f408\fbidi \fnil\fcharset161\fprq2 Calibri Greek;}
{\f409\fbidi \fnil\fcharset162\fprq2 Calibri Tur;}{\f412\fbidi \fnil\fcharset186\fprq2 Calibri Baltic;}{\f413\fbidi \fnil\fcharset163\fprq2 Calibri (Vietnamese);}{\flomajor\f31508\fbidi \fnil\fcharset238\fprq2 Arial CE;}
{\flomajor\f31509\fbidi \fnil\fcharset204\fprq2 Arial Cyr;}{\flomajor\f31511\fbidi \fnil\fcharset161\fprq2 Arial Greek;}{\flomajor\f31512\fbidi \fnil\fcharset162\fprq2 Arial Tur;}{\flomajor\f31513\fbidi \fnil\fcharset177\fprq2 Arial (Hebrew);}
{\flomajor\f31514\fbidi \fnil\fcharset178\fprq2 Arial (Arabid);}{\flomajor\f31515\fbidi \fnil\fcharset186\fprq2 Arial Baltic;}{\flomajor\f31516\fbidi \fnil\fcharset163\fprq2 Arial (Vietnamese);}
{\fdbmajor\f31518\fbidi \fnil\fcharset238\fprq2 Times New Roman CE;}{\fdbmajor\f31519\fbidi \fnil\fcharset204\fprq2 Times New Roman Cyr;}{\fdbmajor\f31521\fbidi \fnil\fcharset161\fprq2 Times New Roman Greek;}
{\fdbmajor\f31522\fbidi \fnil\fcharset162\fprq2 Times New Roman Tur;}{\fdbmajor\f31523\fbidi \fnil\fcharset177\fprq2 Times New Roman (Hebrew);}{\fdbmajor\f31524\fbidi \fnil\fcharset178\fprq2 Times New Roman (Arabid);}
{\fdbmajor\f31525\fbidi \fnil\fcharset186\fprq2 Times New Roman Baltic;}{\fdbmajor\f31526\fbidi \fnil\fcharset163\fprq2 Times New Roman (Vietnamese);}{\fhimajor\f31528\fbidi \fnil\fcharset238\fprq2 Calibri Light CE;}
{\fhimajor\f31529\fbidi \fnil\fcharset204\fprq2 Calibri Light Cyr;}{\fhimajor\f31531\fbidi \fnil\fcharset161\fprq2 Calibri Light Greek;}{\fhimajor

[alto] ALTO Session at IETF-98

[Jan Seedorf]

ALTO-Folks,

just to let you know: Vijay and I both will be at IETF-98 in Chicago and 
have requested a slot for an ALTO session at IETF-98.


Happy new year!

 - Jan


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] No virtual interim meeting

[Jan Seedorf]

Dear all,

since there was only very minor interest in having an ALTO virtual 
interim, we decided not to have one (at this point in time).


As a reminder, there will be no physical ALTO session at the IETF 
meeting in Seoul. However, Vijay and I both plan to be at the IETF 
meeting in Chicago, so we should most likely have a regular ALTO session 
at IETF Chicago in March 2017.


 - Jan


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] RFC 7971 on Application-Layer Traffic Optimization (ALTO) Deployment Considerations

[Jan Seedorf]

+1 :)

 - Jan


On 07/10/16 14:46, Vijay K.Gurbani wrote:

Authors: Congratulations!  This has been a long time overdue, but Jan
and I are glad that the RFC is finally out.  Awesome!

Cheers,

On 10/06/2016 07:34 PM, rfc-edi...@rfc-editor.org wrote:

A new Request for Comments is now available in online RFC libraries.


RFC 7971

Title:  Application-Layer Traffic Optimization (ALTO)
Deployment Considerations
Author: M. Stiemerling,
S. Kiesel,
M. Scharf,
H. Seidel,
S. Previdi
Status: Informational
Stream: IETF
Date:   October 2016
Mailbox:mls.i...@gmail.com,
ietf-a...@skiesel.de,
michael.sch...@nokia.com,
hsei...@benocs.com,
sprev...@cisco.com
Pages:  77
Characters: 188372
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-alto-deployments-16.txt

URL:https://www.rfc-editor.org/info/rfc7971

DOI:http://dx.doi.org/10.17487/RFC7971

Many Internet applications are used to access resources such as
pieces of information or server processes that are available in
several equivalent replicas on different hosts.  This includes, but
is not limited to, peer-to-peer file sharing applications.  The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications that have to select one or several hosts
from a set of candidates capable of providing a desired resource.
This memo discusses deployment-related issues of ALTO.  It addresses
different use cases of ALTO such as peer-to-peer file sharing and
Content Delivery Networks (CDNs) and presents corresponding examples.
The document also includes recommendations for network administrators
and application designers planning to deploy ALTO, such as
recommendations on how to generate ALTO map information.

This document is a product of the Application-Layer Traffic 
Optimization Working Group of the IETF.



INFORMATIONAL: This memo provides information for the Internet 
community.

It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto




- vijay


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] review of draft-ietf-alto-incr-update-sse-02

[Jan Seedorf]

on tag.

This sentence is difficult to read. Do the "" around the second "tag"
make sense?  Is a "the" missing?


If that version is still current, the ALTO
Server SHOULD omit sending a full replacement update at the start of
the stream (see Section 7.6.2).

Could you explicitly state what it should do (send?) instead? Just nothing?

If that version is not current, the server MUST ignore the "tag" field.

Could you explicitly state what it should do (send?) after ignoring?
Just nothing? The full map?



Sec 7.3:

... SHOULD send the full-replacement message soon after the change ...

If I remember correctly we had a discussion on this list some years
ago whether RFC2119 language is adequate only for behavior that
can be blackbox-tested, or also for behavior that needs a whitebox test
to validate. I think we agreed that both is ok.
But "SHOULD" in conjunction with "soon" seems to me like going
a step too far.



Sections 8.2 and 8.6

If a request is successful, the server returns an HTTP "200
OK" response with Content-Type "text/plain" and no data.

is this good practice?  Maybe better "204 No Content" ?



sec 12.3

Hence when sending a full network map or cost map, an ALTO
server SHOULD insert a new-line character periodically.
Approximately every 2,000 characters should be sufficient for most
SSE clients.

an uppercase SHOULD in conjunction with a very vague lowercase should?

Can this be expressed more specific?

Hence an ALTO server SHOULD NOT send lines longer than 2000 characters.
This can be achieved by adding new-line characters periodically.

Or is this someone else's problem and has been discussed and specified
elsewhere, so we can just add a pointer to that document?




sec 13.2

An outside party which can read the update stream response can obtain
the control URI and use that to send a fraudulent "remove" requests,
thus disabling updates for the valid client.  This can be avoided by
encrypting the stream (see Section 15 of [RFC7285]).

This remedy implies that the server must use control URIs with enough
randomness, so an attacker cannot guess them. Should that be added in 8.1?
Or can we find a better mechanism to actually authenticate and autorize
requests to the control URI?




   -- Sebastian

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] TR: I-D Action: draft-ietf-alto-multi-cost-03.txt

[Jan Seedorf]

vailable by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

_______
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] my email address

[Jan Seedorf]

Dear all,

my new email address is "jan.seed...@hft-stuttgart.de". It has come to 
my attention that some of you are still using my NEC email address; that 
does not work anymore. So please use "jan.seed...@hft-stuttgart.de" in 
the future for individual mails to me.


See you all in Berlin,
 - Jan

--
********
Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I am reviewing Server-Sent Events(SSE)

[Jan Seedorf]

Dear Mingming,

thanks for doing a review of the draft, this is much appreciated. And 
welcome to the ALTO WG.


Since you are new to the working group, we still would like to see an 
additional review from someone who has been active in the WG for some 
time, as such a person can check consistency with WG discussions, other 
docs, etc.


 - Jan

Am 06.07.2016 um 13:21 schrieb Mingming Chen:

Hi all,
This is Mingming Chen, I am new in alto ietf group. I am reviewing 
/ALTO Incremental Updates Using SSE/ and will give some feedback soon. 
I am glad to discuss with other reviewers of this draft. Thanks!



Best Regards,
Mingming Chen




___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Call for adoption of draft-randriamasy-alto-cost-calendar-05

[Jan Seedorf]

Dear all,

during the last ALTO Virtual Interim Meeting (see 
https://www.ietf.org/proceedings/interim/2015/10/27/alto/minutes/minutes-interim-2015-alto-1) 
we agreed to discuss the adoption of 
draft-randriamasy-alto-cost-calendar on the mailing list. The document 
has been presented many times at IETF meetings and been discussed on the 
list.


The chairs are hereby asking opinions on adopting 
https://tools.ietf.org/html/draft-randriamasy-alto-cost-calendar-05 as 
Working Group Item document in the ALTO Working Group. Please speak up 
and state your opinion on this issue until Monday, July 18, 2016.


Jan & Vijay

--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Working Group Last Call on draft-ietf-alto-multi-cost-02

[Jan Seedorf]

Dear all,

during the last ALTO Virtual Interim Meeting (see 
https://www.ietf.org/proceedings/interim/2015/10/27/alto/minutes/minutes-interim-2015-alto-1)
 there was consensus on moving draft-ietf-alto-multi-cost to Working Group Last 
Call. In the meantime, the authors have also published a new version of the 
document (-02). The chairs believe the document is ready for WGLC.

Today will begin a two-week WGLC on 
https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02. Please post any 
comments, questions, or concers you might have on the ALTO mailing list.

The WGLC will end on Monday, July 18, 2016.

At this time, we (the chairs) are also looking for volunteers to provide an 
individual review for the draft. This is important to ensure that the documents 
we move on to the IESG have been double-checked in detail by a non-author of 
the document. So please let the chairs know if you can volunteer for doing the 
individual review for this document.

Jan & Vijay

--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Working Group Last Call on draft-ietf-alto-incr-update-sse-02

[Jan Seedorf]

Dear all,

during the last ALTO Virtual Interim Meeting (see 
https://www.ietf.org/proceedings/interim/2015/10/27/alto/minutes/minutes-interim-2015-alto-1)
 there was consensus on moving draft-ietf-alto-incr-update-sse to Working Group 
Last Call. In the meantime, the authors have also published a new version of 
the document (-02). The chairs believe the document is ready for WGLC.

Today will begin a two-week WGLC on 
https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-02. Please post any 
comments, questions, or concers you might have on the ALTO mailing list.

The WGLC will end on Monday, July 18, 2016.

At this time, we (the chairs) are also looking for volunteers to provide an 
individual review for the draft. This is important to ensure that the documents 
we move on to the IESG have been double-checked in detail by a non-author of 
the document. So please let the chairs know if you can volunteer for doing the 
individual review for this document.

Jan & Vijay


--

Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Spam-Level: LOW ; Working on a new draft on applying ALTO for ExaScale Science Applications.

[Jan Seedorf]

Dear Qiao,

this sounds interesting, can you elaborate a bit more what makes 
"ExaScale Science Data Transfers" different from other networking 
applications (e.g. what are the unique properties of such data 
transfers) and how ALTO can help?


thanks,
Jan

Am 03.07.2016 um 06:25 schrieb Qiao Xiang:

Hi All,

I am working with a team from CalTech on a new draft titled "Traffic 
Optimization for ExaScale Science Applications" for IETF 96. This 
draft will introduce our current efforts on applying ALTO for ExaScale 
Science Data Transfers. I am wondering if anyone is interested in 
working with us together? Please let me know. Thanks. :-)




Best
Qiao Xiang
--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
********
Prof. Dr. Jan Seedorf
jan.seed...@hft-stuttgart.de

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de




 

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Minutes from the ALTO Session at IETF-93 uploaded

[Jan Seedorf]

Dear all,

since we received no corrections/comments, I have just uploaded the notes from 
the IETF-93 ALTO session (as below) via the proceeding manager.


-  Jan

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jan Seedorf
Sent: Dienstag, 28. Juli 2015 21:42
To: alto@ietf.org
Subject: [alto] Minutes from the ALTO Session at IETF-93

Dear all,

below are the minutes from the ALTO Session at IETF-93 last week. Thanks again 
to Lyle for taking notes!

Please let us (the chairs) have any comments/edits/corrections you might have.


-  Jan



**

ALTO WG Meeting Notes



1520-1530 - Administrivia Chairs 10'



Interop Event

- Skype and remote / local team

- 2 client / server combo & 1 solo client & 1 solo server

- No protocol bugs but found a couple of minor implementation bugs

- First interop since approval of RFC 7285

- Proposal from Richard Yang to do this remotely at any time and we could host 
at any IETF meetings

- Snapshot of test was shown



Milestone Dates

- behind charter miletsone dates

- chairs to recalibrate after IETF Prague

- we have very matured proposals for the chartered items so Chairs feel 
comfortable about progress



draf-alto-deployments status update given

chairs to prepare



Server Side Notifications (sse)

- adopted as wg item since last IETF

- solves multiple wg charter items

- an update from Wendy has been made

- How to move on is the question?

- 2-3 slides for status is available and may be presented at the end of this 
meeting

- authors feel it is very mature

- no comments were made on this when asked



multi-cost draft

- IPR has been declared on this document

- if one have comments they are urged to comment on mailing list

- as long as the wg knows what they are looking at the IETF does not take a 
position on it but they do take issue with any lack of awareness of IPR



alternative server discovery

- one item is presented to day and we have no alternatives so we may need to 
move on today



Endpoint properties (2 proposals)

- both items to be discussed

- this is a charter item



Agenda Bashing? None



1530-1540 - Inter-ALTO communication problem P. Wydrych 10'

statement

draft-dulinski-alto-inter-problem-statement-02



- discussed changes - rewritten from scratch due to the age of the document

- 11 use cases reduced to 3

- general architecture was presented

- UC 1 - Remote View of Topology

- can calculate cost of sending data

- cannot calculate cost of receiving data (w/o inter-ALTO)

- UC 2 - Detailed Information on Remote Topology

- UC 3 - Partitioned Networks

- Security Issues

- Next Steps

- WG adoption?

WG chair - we will not adopt a document to adopt an item not in the chair

if wg is interested then we will proceed with document but not accept it

- Individual Comment - The problem should be solved but we need to think about 
the process

- Splitting this document up was done on advice of others

- A couple have

- Vijay - one way to move ahead is AD sponsored draft

- Some interest expressed by Sebastian and a others

Conclusion - We move along with agenda an discuss how to proceed on the mailing 
list



1540-1550 - Path extensions for the ALTO P. Wydrych 10'

protocol

draft-wydrych-alto-paths-00



- No way to ask for cost of specific path in ALTO

- Multiple Use Cases presented

- introduces ppid (path pid)

- network map and cost map was presented

- endpoint cost service shown

- Path Computation Service shown

- Question -

- W. Roome - question on the cost map representation

- L. Bertz - expressed usefulness for operators

- Individual comment - expressed other considerations that need to be made in 
the document

- interest in the wg and details need to be worked out - we dein

1550-1600 - Multiple ALTO information sources S. Kiesel 10'

and partitioned knowledge

draft-kiesel-alto-xdom-disc



where are we

- defined dhcp to recommend an alto server URI

- 7285

- we will not standardize the backend (database)

problem statement

- we have multiple sources

- an alto client does not always care about optimizing for itself (an on behalf 
of request)

- if an ALTO server knows everything would it tell us

> we need to address this problem

Options presented for info replication & request forwarding

Use algorithm based on DNS to resolve IP address to a URI

Ask - to be adopted

Technical Questions - None

2-3 have read latest version of the draft

Since only a few folks have read the latest version the question of adoption to 
the mailing list

Common Pietr - We need some sort of discovery service and had some discussion 
regarding a search engine

Wendy - notes that a registry may be useful and reverse DNS may be flaky

WG adoption cannot be taken now (due to low readership)

Jan asked Sebastian to start discussion of adoption on the mailing list



1600-1610 - Extended endpoint properties for H. Song 10'

ALTO

draft-deng-alto-p2p-ext-06



- Statu

[alto] Minutes from the ALTO Session at IETF-93

[Jan Seedorf]

en offline)

- Authors of both documents agree the two (this and Wendy's) are orthogonal



1610-1620 - Unified and extensible approach to W. Roome 10'

ALTO properties

draft-roome-alto-unified-props-00



- some properties are service specific and some are not, e.g. CIDRs

- Endpoint inheritence is realisitc

- ALTO EP service is POST only

- Make the Property Definition independent of the domain

- Each map may have a set of network properties

- 2 new property map services to replace existing EP service

- Updates 7285

- Drop Wendy's previous proposl



- Authors agree documents do not complete because

Wendy's is a replacement of EP Service in 7285

Previous proposal defines new properties



Jan -

Notes the other proposal is in the chartered

The charter is not precise as to whether this draft is out of the charter scope



Sebastian - not a question of XOR drafts and that both drafts are useful and 
should be merged

Proposes p2p draft be adopted

We agree we don't want to merge them (per people in the room)

Pietr - notes that he likes both drafts

- first draft has very specific properties

- second has nice features

- Sabin - both drafts are important

- second draft reduces data to converge between the

H - uses existing ep service in his I-d draft-deng-alto-p2p-ext

Vijay - thinks more discussion is necessary

L Bertz - thinks second draft meets the reduction of over the wire reduction 
objective in the chartered

Conclusion - more discussion is required and the documents can be progressed



1620-1630 - ALTO map calculation from network H. Seidel 10'

data

(No internet-draft)



- Continuous update of alto network information is required

- Multiple sources of the information exists

- Compile internal network map (displayed on slide)

- Executed large map construction (800 routers) with exclusion and other 
filters to generate network and cost maps

- Comment - Pietr - good to see presentation where an ALTO server is processing 
full BGP data and receiving updates periodically

- Jan note hows that this is useful for

- Main idea of presentation is to provide information as opposed to creating a 
draft



1630-1640 - Multi-cost ALTO S. Randriamasy 10'

draft-ietf-alto-multi-cost



(Reduced to 5 minutes)

- Main driver is backwards compatibility with legacy clients

- Testable Cost Types discussed - can test a value on a metric w/o the need to 
return it

- Next Steps - this is a wg document and mature document but we need comments 
from the team on the mailing list



1640-1650 - ALTO cost calendar S. Randriamasy 10'

draft-randriamasy-alto-cost-calendar-04



- Overview of changes

- Main updates the service applies to all metrics and it is now backwards 
compatible

- Request WG adopton

- no time for discussion

- need feedback from WG on mailing list to adopt it?

- is this the right level?

- encourage others to read the draft

1650-1700 - Routing State Abstraction Service W. Roome / Y.Lee 10'

draft-gao-alto-routing-state-abstraction-00



- Wendy presenting on behalf of Richard

- Client requests the level of abstraction it wants to see from the ALTO server

- Client uses OpenFlow like list to describe what they want

- Are we interested in this approach?

- only 1 person has read it - Jan asked for folks to read it



1700-1710 - Large Data Transfer Coordinator H. Song 10'

ddraft-wang-alto-large-data-framework-00



- Due to time we deferred comments to the mailing list

1710-1720 - Spill over/Conclusion/Wrap-up Chairs/WG 10'



- General comment of encouraging WG to read each others' documents. Authors are 
encouraged to read each other's work.


**



Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Please read the documents from other WG participants

[Jan Seedorf]

Hi Haibin,

I am not sure about that; for now, let's try "the chairs strongly encourage the 
WG members to read the documents and review them, in particular for the 
chartered items, where in several cases mature drafts exist". Let's see how far 
this gets us until the next IETF :)


-  Jan

From: Songhaibin (A) [mailto:haibin.s...@huawei.com]
Sent: Dienstag, 28. Juli 2015 08:04
To: Jan Seedorf; alto@ietf.org
Subject: RE: Please read the documents from other WG participants

I agree. Shall we try something like, if you would like to get a slot to 
present your draft, it's a must that at least you should read another draft and 
send the comments to the list? :)

Best Regards!
-Haibin

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jan Seedorf
Sent: Thursday, July 23, 2015 10:20 PM
To: alto@ietf.org<mailto:alto@ietf.org>
Subject: [alto] Please read the documents from other WG participants

Dear all,

I think we are seeing good progress with all chartered items, which is great, 
and I am convinced there is good energy in the WG to finish all the milestones.

What is sometimes missing---as I mentioned in the ALTO session this week here 
at IETF-93---is people (other than the authors) reading the drafts and 
providing feedback to the mailing list. E.g., in order to adopt a draft as WG 
item, I would like to see comments from other people on the mailing list saying 
they have read the draft and what they think of it. One good example is how 
Richard did it for multi-cost (see
https://mailarchive.ietf.org/arch/msg/alto/RUjTEP9-iIKd2txEANZCDDOMHkg) in 
order to move it forward towards WGLC.  Obviously, if you read a draft and 
think it is very good and you have fewer or nor comments that is also fine, but 
please say so on the mailing list. Also, if you have a draft of your own that 
you want to progress and receive feedback on, why not start by reading other 
people's drafts and help them make progress; I am sure people will then also 
return the favour and read your draft and improve it.

As chairs, our role is to make sure that drafts being adopted as WG item have 
the backing of the majority of the WG (rough consensus) and drafts entering 
WGLC are ready for publication, so that we do not embarrass ourselves in front 
of the IESG.


-  Jan (with chair hat on)

============
Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Please read the documents from other WG participants

[Jan Seedorf]

Dear all,

I think we are seeing good progress with all chartered items, which is great, 
and I am convinced there is good energy in the WG to finish all the milestones.

What is sometimes missing---as I mentioned in the ALTO session this week here 
at IETF-93---is people (other than the authors) reading the drafts and 
providing feedback to the mailing list. E.g., in order to adopt a draft as WG 
item, I would like to see comments from other people on the mailing list saying 
they have read the draft and what they think of it. One good example is how 
Richard did it for multi-cost (see
https://mailarchive.ietf.org/arch/msg/alto/RUjTEP9-iIKd2txEANZCDDOMHkg) in 
order to move it forward towards WGLC.  Obviously, if you read a draft and 
think it is very good and you have fewer or nor comments that is also fine, but 
please say so on the mailing list. Also, if you have a draft of your own that 
you want to progress and receive feedback on, why not start by reading other 
people's drafts and help them make progress; I am sure people will then also 
return the favour and read your draft and improve it.

As chairs, our role is to make sure that drafts being adopted as WG item have 
the backing of the majority of the WG (rough consensus) and drafts entering 
WGLC are ready for publication, so that we do not embarrass ourselves in front 
of the IESG.


-  Jan (with chair hat on)


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Room Info ALTO interim tonight

[Jan Seedorf]

For all implementers participating in the ALTO interop tonight, here is the 
room info:


Meeting Name: ALTO Interop Testing

Assigned Room: Florenc

Assigned Date: 07/20/2015

Assigned Start Time: 20:00:00

Assigned End Time: 23:00:00

Looking forward to an interesting and hopefully successful event!


-  Jan


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Updated (draft) agenda posted

[Jan Seedorf]

Dear all,

please note that in the updated agenda the timeslots are now 10 instead of 15 
minutes (as we have a couple more presentations). As we have a packed agenda 
and want to give everyone the chance to present, please plan your presentation 
slot accordingly and make sure you stick to the time allocated.

Thanks,
Jan

-Original Message-
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
Sent: Sonntag, 19. Juli 2015 20:05
To: alto
Subject: [alto] Updated (draft) agenda posted

Folks: The updated agenda has been posted for the Prague IETF.
Please see https://datatracker.ietf.org/meeting/93/agenda/alto/

Jan and I believe that this agenda includes the last minute requests that we 
could accommodate.  Please eyeball the agenda and let us know of any omissions.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Session / Agenda at IETF-93

[Jan Seedorf]

Dear all,

we received quite a few late agenda requests, and are trying to accommodate 
them as much as possible. We are currently revising the agenda and hopefully 
will publish an updated agenda tomorrow (Sunday).

In the meantime, all authors on the current agenda 
(https://tools.ietf.org/wg/alto/agenda): please send us your slides asap, and 
be aware that you may get a little less time (as there are many late requests, 
see above).

See you all on Tuesday in the ALTO session (Tuesday, July 21, 2015 1520-1720), 
or some of you already on Monday evening at the ALTO interop event.


-  Jan


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Session at IETF-93

[Jan Seedorf]

The ALTO slot at IETF-93 will be


***

Tuesday, Afternoon Session II 1520-1720

Room Name: Berlin/Brussels size: 100
***

Please note that the agenda may potentially change on short notice.

See you all in Prague,


-  Jan


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Interop at IETF-93 in Prague

[Jan Seedorf]

Dear all,

as discussed on this list and requested by several of you, we have arranged a 
room for an ALTO interop at IETF-93 as follows:

** MONDAY, July 20th, 20:00-23:00 **

There has already been some good discussion on this list regarding the interop, 
plus a draft from Wendy. Please continue this discussion, so that we can make 
the best use of the time in Prague.


-  Jan


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Interop test

[Jan Seedorf]

Regarding the date/time: the chairs can likely only make it on one of the 
following evenings during the IETF week: MON, WED, THU. We are aiming at 3-4h. 
Does that work for the people interested?

We have contacted the secretariat to tentatively reserve a room etc.

 - Jan

-Original Message-
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Samstag, 30. Mai 2015 12:48
To: Bertz, Lyle T [CTO]
Cc: Wendy Roome; alto@ietf.org
Subject: Re: [alto] Interop test

It is great to open email and see these discussions!

First, answer to Lyle's P.S. question: We are looking at an interop in the July 
IETF meeting. Does this work for you? We sure hope that your team can 
participate.

I agree that denoting some metrics to be a formal metric is a great idea. An 
immediate benefit coming to mind is that it allows compression, for example, 
only half of the cost matrix need to transmitted.

I particularly liked the idea of defining the (network) graph metrics.
Your suggestion  appear to me to have two directions:
(1) still use the cost map framework and defining graph metrics between pairs 
of PIDs (i.e., metrics between a pair of nodes in a graph);
(2) provide overall network (graph) properties; that is, provide summary 
properties of the overall network topology (periphery comes to mind).

I can see a unifying framework such as there is a hierarchy of network graphs, 
and at each level, one can define properties on a network node or a pair of 
nodes. Assume the highest level is a single node representing the overall 
topology, and then such a compound node can have properties such as 
center/periphery).

Am I too off in understanding your ideas?

Thanks!

Richard

On 5/29/15, Bertz, Lyle T [CTO]  wrote:
> Wendy,
>
>
>
> I worked on asymmetric distance theory in graphs - specifically max 
> distance and sum distance so I can definitely say the asymmetry is not an 
> issue and
> you should assume that asymmetric metrics exist in a digraph.   In fact,
> distance is defined at the minimum value of the directed distance from 
> u to v or v to u.
>
>
>
> wrt to your statement d(x,x)=0 is correct because of granularity (that x is
> actually a new set where and x1 and x2 are actually involved).   Such
> summarization would be better described as common subgraph such as a 
> periphery, center, status or median.  For example, if x1 and x2 are in the
> center or periphery we would expect status measurements to be similar.   In
> general we would not measure distance between x1 and x2 but but merely 
> talk about periphery elements as 'x'.  Precision is a whole other 
> matter as well.
>
>
>
> I think identifying metrics that follow formal metric definition is
> definitely a great idea.   For clients and servers we can identify other
> graph metrics.  The two that come to mind are center and periphery of a
> graph.   Where asymmetry is present we can apply max and sum distance to
> yield the center and periphery versions for max and sum distance.
>
>
>
> These metrics and definitions are used quite often in computing edge 
> of networks, how to merge two networks together, Steiner cut selections, etc.
> Periphery is the most interesting as it tells a lot about the status 
> of node traffic and hints for placement, e.g. nfv instance selection 
> in MANO when implementing a VNF FG - I could see that being useful for 
> both client and servers.
>
>
>
> Lyle
>
>
>
> 
> From: Wendy Roome 
> Sent: Friday, May 29, 2015 4:06 PM
> To: Bertz, Lyle T [CTO]; Y. Richard Yang
> Cc: alto@ietf.org; Hans Seidel; alto-...@lists.opendaylight.org
> Subject: Re: [alto] Interop test
>
> Lyle,
>
> I haven't used metric spaces since the days of keypunches, so it took 
> a while to blow the cobwebs out of that memory bank. :-)
>
> I don't think ALTO cost metrics could ever meet the requirements for a 
> metric space. The problems:
>
> * A true metric d(x,y) must be defined for all x & y. ALTO does not 
> require that the cost be defined for all pairs.
>
> * For a metric, d(x,y) = d(y,x) for all x,y. ALTO costs represent 
> communication links, and are potentially asymmetric. Eg,  the download 
> bandwidth can be higher than the upload bandwidth.
>
> * For a metric, d(x,x) = 0 for all x. For ALTO, the cost within a PID 
> frequently is greater than 0.
>
> * For a metric, d(x,y) = 0 means x = y. We *might* be able to define 
> ALTO costs so that is possible, but I have my doubts.
>
> * For a metric, d(x,z) <= d(x,y) + d(y,z) for all y. For ALTO, that is 
> tempting requirement, and I cannot think of an obvious counter 
> example. But I doubt that would help without the other requirements.
>
> So we could not require *every* ALTO cost metric to qualify as a 
> mathematical metric. But we could define a particular cost as 
> satisfying those rules, and (say) identify it in the IRD.  Can you 
> explain how that would benefit clients or servers? One obvious 
> advantage is that the cost matrix c

[alto] Minutes from IETF92 uploaded

[Jan Seedorf]

Please check the minutes, and let the chairs know if you find something that 
needs to be corrected.


-  Jan


Prof. Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 
36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu<mailto:jan.seed...@neclab.eu>

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB, Registered in England 2832014

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO implementation interoperability

[Jan Seedorf]

We have also put this topic on the chair slides for the session in Dallas to 
get feedback from the room, but please also continue raising your opinion on 
this here on the ML.


-  Jan

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Donnerstag, 19. März 2015 22:26
To: Hans Seidel
Cc: IETF ALTO
Subject: Re: [alto] ALTO implementation interoperability

Hi Hans,


On Thu, Mar 19, 2015 at 6:49 AM, Hans Seidel 
mailto:hsei...@benocs.com>> wrote:
It will be cool to have an interop for the summer IETF. For those who are 
interested, some of us are working on having an open-source ALTO server running 
in ODL. We are slightly behind schedule, but should be able to catch up in 
Apr., after IETF. If there is anyone who is interested in collaboration, you 
are more than welcome.

I also like the idea of an interop for the summer IETF in Prague. Since I am 
rather new to the IETF community, I am not very familiar with the procedures 
but if I can be of any help, let me know.

Wonderful! Some of us here will want to engage in the development of an interop 
in Prague as well. It will be nice to coordinate and get started soon, say 
after this IETF.

Thanks!

Richard


Hans




Richard



Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: 
vkg@{bell-labs.com,acm.org}
 / vijay.gurb...@alcatel-lucent.com
Web: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=RUjSP5rpFsp8V2Y0xuG9_3pFcAAsDEjzi2YQNNaMKfY&e=
   | Calendar: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=wY56fXByx0Kd3boQqPHpBjX7uzem5fDJHZAW1FIv_Mc&e=
___
alto mailing list
alto@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=JAiHH7palOiAkB3m6zdiENhShLMINWuIhPrijAeT0iQ&e=





--

BENOCS GmbH

Dipl.-Ing. Hans Seidel

Winterfeldtstr. 21

10781 Berlin

Germany

Phone: +49 - 30 / 577 0004-0

Email: hans.sei...@benocs.com

www.benocs.com



Board of Management:

  Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese

Commercial Register: Amtsgericht Bonn HRB 19378
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Request for comments on two changes for RFC7285-to-be

[Jan Seedorf]

> (2) However, some authors feel that we should not enforce too strong a
> requirement to make deployment harder. Hence, instead of changing the
> aforementioned MAY to MUST, these authors feel that it is better to make
> the pid endpoint property optional. Hence, we make the two changes of E1
> and E6.
I agree with this assessment and am therefore in favour of the changes from 
"MUST" to "MAY".

 - Jan

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
> Sent: Friday, August 08, 2014 6:05 AM
> To: IETF ALTO
> Cc: Megan Ferguson
> Subject: [alto] Request for comments on two changes for RFC7285-to-be
> 
> Dear ALTOnians,
> 
> The authors of the ALTO Protocol are finalizing the final version, to be
> published as RFC 7285. We seek your comments/feedback on two non-
> editorial changes.
> 
> But first, the text, XML, and comprehensive diff files are available at:
> http://www.rfc-editor.org/authors/rfc7285.txt
> http://www.rfc-editor.org/authors/rfc7285.xml
> http://www.rfc-editor.org/authors/rfc7285-diff.html
> 
> A summary of the key changes is listed below:
> E1: the change from MUST to MAY in Section 7.1.1
> E2: update from "misses" to "omits" in Section 8.5.2
> E3: the addition of MUST and text addition to Section 10.8.1
> E4: update from "both" to "either...or" in Section 11.2.3.6
> E5: text update to Section 11.4.1.3, paragraph 1
> E6: text deletion from Section 11.4.1.4. The deleted text is "In particular, 
> the
> information resource closure MUST provide the look up of pid for every ALTO
> network map defined."
> 
> The AD has approved all changes except E1 and E6, which are non-editorial.
> 
> There are two reasons for E1 and E6:
> 
> (1) Make the document consistent. Specifically, the first paragraph of Section
> 11.4.1 states that "An endpoint property resource provides information
> about properties for individual endpoints.  It MAY be provided by an ALTO
> server." Without E1 and E6, the document will imply that at least one
> endpoint properties service (i.e., one to provide pid) must be provided.
> Hence, one way to achieve consistency is to change the MAY in the first para
> of 11.4.1 to be  MUST.
> 
> (2) However, some authors feel that we should not enforce too strong a
> requirement to make deployment harder. Hence, instead of changing the
> aforementioned MAY to MUST, these authors feel that it is better to make
> the pid endpoint property optional. Hence, we make the two changes of E1
> and E6.
> 
> Your comments and feedback will be greatly appreciated. We will wait for
> one week for any feedback.
> 
> Thanks a lot.
> 
> Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] JSON Patch vs. custom representation for incremental updates

[Jan Seedorf]

Wendy, Sebastian,

I see your points. The thing that worries me is that one of the arguments _not_ 
to use ALTO for CDNI-FCI in the CDNI WG has been that it will take some time 
for incremental updates to be available for ALTO. We have always argued that 
incremental updates for ALTO are "on the way" (which indeed is/was the case). 
Now, from that perspective, if the "default" ALTO solution for incremental 
updates would only work for classic network/cost maps, and would not work for 
our ALTO CDNI FCI service, that is not desirable.

On the other hand, there are some differences when using ALTO for CDNI compared 
to P2P that have implications on incremental updates: CDNI-FCI is CDN service 
provider to CDN service provider (so you can expect a high capacity link 
between the two); the number of PIDs in a CDNI FCI network map footprint is 
likely much smaller than 5000; the overall size of a CDNI FCI object-format-map 
is likely much, much smaller than a cost map for a large ISP. All of these 
differences actually imply that incremental updates are not so crucial for the 
CDNI case than for e.g. the P2P case: if a uCDN has e.g. 4 dCDNs, the overall 
amount of data being sent over the network is much smaller than if an ISP has 
200.000 P2P users, so fetching the complete JSON object each time may be ok for 
CDNI-FCI.

So we may have good arguments for saying ALTO network/cost map service has a 
specific incr. update solution, and ALTO CDNI FCI service uses JSON patch.

I guess I would like to hear other opinions ...

 - Jan

> -Original Message-
> From: Wendy Roome [mailto:w.ro...@alcatel-lucent.com]
> Sent: Thursday, July 10, 2014 10:21 PM
> To: Jan Seedorf; IETF ALTO
> Subject: Re: [alto] JSON Patch vs. custom representation for incremental
> updates
> 
> I respectfully disagree that using JSON Patch for cost & network map
> incremental updates would make it any easier to provide incremental update
> for future services.
> 
> You¹d have a point if JSON Patch solved the whole incremental update
> problem without any additional protocol specification. E.g., if we could
> just say, ³For incremental update, use JSON Patch [RFC 6902]², and Shazam!
> we have incremental update.
> 
> Unfortunately it¹s not that easy. The format used to represent the deltas
> < JSON Patch vs service-specific update commands < is only a small part of
> the incremental update mechanism. For an incremental update service to a
> map, we have to specify how the client locates the service (e.g., its
> media type), how the client tells the server what version the client has
> now, etc, etc.
> 
> Of course, if it turns out that JSON Patch is a good way to represent the
> deltas for the CDN services you mentioned, then the associated incremental
> update service an use JSON Patch. But we still need to define that
> service. And that would require a new RFC, or at least a section in a new
> RFC.
> 
> BTW, one of the problems I see with JSON Patch is that JSON does not
> define a ³set² type, so everyone uses arrays instead. Your CDN service
> example has several arrays that I believe are really sets. Arrays are fine
> for exchanging sets, but they make it difficult for any JSON library to
> automatically create an efficient JSON Patch for the changes between
> versions. For example, if the values are permuted into a different order,
> the set hasn¹t changed < but the array is totally different. So JSON Patch
> would have to update the whole thing, as opposed to saying ³no change."
> 
>   - Wendy
> 
> On 07/10/2014, 10:26, "Jan Seedorf"  wrote:
> 
> >Hi Wendy,
> >
> >What about future, new ALTO services (e.g. as proposed in
> >http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-07)?
> >
> >I am not a fan of JSON patch, but a solution for incremental updates
> >based on JSON patch should be much more future-proof with respect to
> new,
> >future ALTO services that convey JSON objects other than network/cost
> >maps, right?
> >
> >- Jan
> >
> 

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] JSON Patch vs. custom representation for incremental updates

[Jan Seedorf]

Hi Wendy,

What about future, new ALTO services (e.g. as proposed in 
http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-07)?

I am not a fan of JSON patch, but a solution for incremental updates based on 
JSON patch should be much more future-proof with respect to new, future ALTO 
services that convey JSON objects other than network/cost maps, right?

 - Jan

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Wendy Roome
> Sent: Wednesday, July 09, 2014 9:15 PM
> To: IETF ALTO
> Subject: Re: [alto] JSON Patch vs. custom representation for incremental
> updates
> 
> Here's why I think we need a representation for incremental updates that's
> tailored to the ALTO data model, rather than using the general JSON Patch
> representation.
> 
> As I understand it, JSON is a standardized way for a computer to create a
> serialized, machine-independent representation of a data structure, send
> that serialization over a stream to another computer, and have the other
> computer recreate that data structure. This is a simplification, of
> course, but I believe that's the goal.
> 
> JSON Patch is a standard way to represent the changes to a data structure,
> ship them to another computer, and have a JSON Patch library on the other
> computer automatically update the remote data structure, with little
> additional work for either computer.
> 
> That's a wonderful goal. Unfortunately that has three problems when we
> apply it to ALTO: (1) JSON does not have data representations that
> directly correspond to the ALTO data structures, so JSON cannot capture
> the semantics of the ALTO data. (2) As a result, JSON Patch is an
> inefficient representation of the legal changes. (3) For the clients who
> need incremental update, that inefficiency is a deal breaker.
> 
> Let's take the last first. What clients need incremental update? Clients
> who keep full cost and network maps. But what clients would do that? After
> all, clients care about costs between endpoints. Clients don't really care
> about PIDs. PIDs are just an abstraction to make the space of endpoints
> more manageable. For most ALTO clients, the Endpoint Cost Service (ECS) is
> exactly what they want, and they'd much rather use that than go though the
> hassle of downloading the maps, searching them, and keeping them
> up-to-date.
> 
> So why would a client use full maps? Because the client needs to lookup
> costs very quickly, and cannot tolerate the delay of querying the ALTO
> Server. For example, a P2P tracker must select, out of 5,000 peers, the 50
> with the lowest cost to a given peer. And a tracker might do that 10 times
> a second.
> 
> As for the second point, incremental update is only necessary for large
> maps. If a map only has 25 PIDs, why bother? Just download a new version.
> What do I mean by "large"? A Network Map with 5,000 PIDs, 250,000
> prefixes, and up to 25,000,000 cost points.
> 
> Yes, that seems huge. Will anyone ever build that large an ALTO server? I
> don't know. But I think a lot of us remember when the ipv4 address space
> seemed infinite. Or when a 100 meg disk was big.
> 
> Now consider point 1: JSON does not do a good job of representing the ALTO
> data. Take Cost Maps. A Cost Map is a square sparse matrix of numbers
> indexed by strings. JSON has no such data structure, so in JSON we
> represent that as a lookup table of lookup tables of costs. But that
> consumes a lot more space than necessary. Furthermore, at least for most
> cost metrics, the values are low precision (do you really think that a
> routingcost of 49.9 is any better than a cost of 50?), and the string
> indexes -- the PID names -- don't change very often.
> 
> So if a client needs to handle a 5,000 x 5,000 Cost Map, and lookup costs
> in microseconds, the client convert the PID names to numbers from 0 to
> N-1, so it can use a sparse numerically indexed array, and it stores the
> costs single-precision floats, not double-precision, to save 100 megs of
> RAM.
> 
> The mismatch is even worse for Network Maps. A Network Map is a lookup
> table from PID names to sets of prefixes. ALTO has lookup tables, but
> doesn't have sets, so we represent the sets by arrays. But this confounds
> JSON Patch, because order matters in arrays. Furthermore, the JSON
> representation does not capture the semantics that a prefix can only be in
> one PID. So if the server moves 1.2.3.4 from PID1 to PID2, JSON Patch
> would need the following update commands:
> 
>  add 1.2.3.4 at index 17 in the array for PID1
>  delete index 6 from the array for PID2
> 
> But if we know the real semantics of ALTO Network Maps, we can represent
> that update as:
> 
>  add 1.2.3.4 to PID1
> 
> The delete from PID2 is implicit.
> 
> Here's the bottom line: Clients who need incremental update will NOT store
> data in a format that looks like JSON data model. Such a client will read
> the JSON data, convert it in a totally different form

[alto] FW: FCI Analysis

[Jan Seedorf]

ALTO Folks,

Just a reminder and FYI: ALTO is currently one of two candidates for the CDNI 
FCI interface (draft-seedorf-cdni-request-routing-alto). Matt below provided a 
good comparison of the ALTO-based approach that Richard Yang and I am 
proposing, and the alternative approach which would be a CDNI-specific 
JSON-based encoding.

 - Jan

-Original Message-
From: CDNi [mailto:cdni-boun...@ietf.org] On Behalf Of Matt Caulfield (mcaulfie)
Sent: Saturday, February 22, 2014 9:51 AM
To: c...@ietf.org
Subject: [CDNi] FCI Analysis

As promised in Vancouver, I have read through the two current FCI proposals 
(along with some of their normative references) and I have put together the 
following analysis. 

The text below first reviews the CDNI Requirements for FCI as well as some of 
the highlights from the FCI Semantics. Next, a short list of (what I feel are) 
the key points from each draft. Finally, my analysis comparing the drafts based 
on their approach to FCI (and not the quality or the level of detail in the 
documents).

If you have not done so already, then I would also  recommend reading Jon 
Peterson's email from February 6 ("footprint and capabilities mechanisms"). 

===
FCI Requirements (draft-ietf-cdni-requirements)
-
The CDNI FCI must allow a dCDN to communicate the following to a uCDN:
1) Ability/willingness of dCDN to handle requests from uCDN
2) Information to facilitate selection of a dCDN by uCDN (e.g. capabilities, 
resources, affinities)
3) Aggregated versions of #1 and #2 in the cascaded CDN case
4) Administrative limits and policies (e.g. max number of requests)
5) Specific capabilities including:
a) delivery protocol
b) acquisition protocol
c) redirection mode (DNS vs HTTP)
d) logging options
e) metadata options
6) Delivery authorization mechanisms (e.g. uri signing)

The FCI must also support extensibility and versioning for new capabilities and 
footprints.

===
FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) 
-
Design Decisions
1) Advertising Limited Coverage - should footprints be binary or rated via 
qualitative score?
2) Capabilities and Dynamic Data - what capabilities are static vs dynamic? If 
dynamic, how dynamic?
3) Advertisement vs Queries - synchronous query response model (per end client 
request) or state replication? 
4) Avoiding / Handling Cheating dCDNs - capabilities should be eventually 
verifiable by the uCDN

Mandatory footprint types:
1) List of ISO Country Codes
2) List of AS numbers
3) Set of IP-prefixes

FCI must be able to convey the entire footprint/capabilities and optionally 
dynamic updates.

Footprints and Capabilities are dependent and tied together. Certain 
capabilities are only available for specific footprints.

Important to note that most footprint information will be agreed upon out of 
band (e.g. via contracts). FCI can be considered a means for providing changes 
or updates to that previously agreed upon set of footprints and capabilities.

===
 FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) 
-
This proposal is based on the ALTO (Application Layer Traffic Optimization) 
protocol (draft-ietf-alto-protocol), currently under development by the ALTO 
working group. ALTO protocol specification is currently an Active 
Internet-Draft in the "Submitted to IESG for Publication" state. 

Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine 
footprint and capabilities of dCDN.

An ALTO Network Map indicates coverage/reachability to groups of endpoints. 
Endpoints are grouped into PIDs. All endpoints within a single PID share the 
same capabilities. 

Each PID is associated with a set of properties. Each property corresponds to a 
capability. The concept of a PID Property Map is defined by 
draft-roome-alto-pid-properties (an active Internet-Draft). The same draft 
defines rules for implicit inheritance of properties for overlapping PIDs (e.g. 
one PID may correspond to a set of IP prefixes which is a subset of another 
PID; in this case, properties in the PID Property Map for the bigger set (i.e. 
shorter IP prefix) also apply to the smaller set (i.e. longer IP prefix)).

Presumably the uCDN is configured with the URI for an ALTO IRD (Information 
Resource Directory) per dCDN. The IRD in turn provides two URIs. One for 
accessing the dCDN's Network Map and another for the dCDN's PID Property Map. 
However, this is not described explicitly.

The draft defines the same basic set of capabilities as defined in the 
requirements but does not describe their encoding in depth.

The ALTO protocol only registers IPv4 and IPv6 endpoint types. Assuming that 
this draft would register ISO

Re: [alto] Text proposal for charter update

[Jan Seedorf]

Hi all,

The text looks good to me and in my view reflects the agreement on 
re-chartering in the ALTO WG.

Just two small comments:
-- "where the host was a peer in a P2P network and desired to be rendezvoused 
with other peers for file sharing" --> When talking about the P2P use case I 
would not use past tense but present tense. P2P is still out there and in 
principle the use case is technically still a valid one. The text in past tense 
reads to me like ALTO has extensively been used for this use case in the past 
(not really true), and should not been used for P2P anymore (also not really 
true)
-- "JSON-path" --> "JSON-patch"

-  Jan

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Enrico Marocco
> Sent: Wednesday, February 19, 2014 5:04 PM
> To: alto@ietf.org
> Subject: [alto] Text proposal for charter update
> 
> Hi all,
> 
> the text below tries to reflect the many discussions about rechartering
> the ALTO WG. We believe that it includes the most relevant work items
> people have shown interest for, yet it is something that can be
> completed in a resonable timeframe (some may find it ambitious, esp.
> according to the WG history, but the level of energy the WG has shown
> recently in the finishing of our main deliverables provides good reason
> for being optimistic).
> 
> Any kind of comment (including nits, +/-1...) are at this point
> extremely important.
> 
> Enrico & Vijay
> 
> 
> Application-Layer Traffic Optimization Working Group Charter
> 
> The ALTO working group was established in 2008 to devise a request/
> response protocol for allowing a host to benefit from a server that is
> more cognizant of the network infrastructure than the host would be.
> The working group has developed an HTTP-based protocol (RFC-to-be) to
> allow hosts to benefit from the network infrastructure by having
> access to a pair of maps: a topology map and a cost map.
> 
> The origins of the ALTO protocol lay in peer-to-peer (P2P)
> applications, where the host was a peer in a P2P network and desired
> to be rendezvoused with other peers for file sharing, real-time
> communications, etc.  It is a testament to the flexibility of the ALTO
> protocol that it is now being considered as a solution for problems
> outside the P2P domain, such as in datacenter networks and in content
> distribution networks (CDN) where exposing abstract topologies helps
> applications.
> 
> To support the emerging new uses of ALTO, certain extensions are being
> sought.  These extensions can be classified as follows:
> 
>  o (Standards Track) Protocol extensions for reducing the volume of
>on-the-wire data exchange required to align the ALTO server and
>clients.  Extensions under consideration are mechanisms for
>delivering server-initiated notifications and partial updates of
>maps.  Efforts developed in other working groups such as Websockets
>and JSON-path will be considered, as well as bespoke mechanisms
>specific to the ALTO protocol.
> 
>  o (Standards Track) Extensions to the base ALTO server discovery
>mechanism (RFC-to-be) for deployment in heterogeneous network
>environments.  Mechanisms under consideration are extensions for
>third-party and anycast-based server discovery.
> 
>  o (Standards Track) Protocol extensions to convey a richer set of
>attributes to allow applications to determine not only "where" to
>connect but also "when" to connect.  Such additional information
>will be related both to endpoints (e.g. conveying server load and
>cache geo-location information for CDN use cases) and to
>endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent
>time-averaged cost values in datacenter networks).
> 
>The working group will specify such extension in coordination with
>other working groups that are also working on the related use cases
>(e.g. cdni, i2rs, lmap).
> 
>  o (Informational) A survey of techniques to formalize the structure
>of a network graph (that can derived from a set of related ALTO
>network and cost maps) in a format that would facilitate advanced
>graph computation.  Such survey will cover both models used in
>popular open-source software (e.g. NetworkX, Blueprints) and models
>being considered in other working groups (e.g. netmod, i2rs).
> 
>  o (Informational) An document on deployment-related issues and
>lessons learned from early implementation experiences.
> 
> When the WG considers standardizing information that the ALTO server
> could provide, the following criteria are important to ensure real
> feasibility:
> 
>  - Can the ALTO service realistically discover that information?
> 
>  - Is the distribution of that information allowed by the operators of
>that service?
> 
>  - Can a client get that information without excessive privacy
>concerns?  Extensions defining new endpoint properties should focus
>on exposing attributes of endpoints that

Re: [alto] Work items for re-chartering

[Jan Seedorf]

Dear all,

I fully support the proposed work items below (1-7) for extending the ALTO 
charter. I believe the many discussions and several side meetings we had in 
2013 (and before) have shown that a) there is significant interest from the 
community in working on these items, and b) that there are multiple important 
use cases that would benefit from these extensions.

Sidenote: Item #5 (PID properties) would be extremely useful for ALTO as a CDNI 
FCI protocol, which Richard Yang and I are proposing in the CDNI WG.

 - Jan

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Thursday, January 23, 2014 8:11 PM
> To: alto
> Subject: [alto] Work items for re-chartering
> 
> Folks: Over the last few IETFs, Enrico and I have solicited feedback
> during face-to-face meetings, WG sessions, hallway conversations, ALTO
> mailing list and private conversations on how to move ahead with respect
> to adopting new work items.
> 
> As we begin the charter discussions, we have identified seven
> work items to propose as additions to the charter.  The first four of
> these work items are fairly uncontroversial.  The last three are work
> items that have a monumental mind share in the ALTO working group and
> have been found to be extremely useful in controlled networks (e.g.,
> VPNs).  However, we have to take some care in defining these such that
> we do not duplicate the functionality available elsewhere (e.g., general
> routing) in ALTO, nor do we take on an aspect that the working group
> does not fully understand.
> 
> Here are the seven items up for discussion:
> 
> 1. Anycast-based server discovery
> (Presented by Reinaldo Penno in IETF 86 and appears to have
> some support for adoption.)
> 
> 2. Third-party server discovery
> (Sebastian Kiesel et al. have been driving this work and it
> also appears to have support.)
> 
> 3. Incremental ALTO map updates
> (Side meeting held during IETF 86; two proposals have been
> studied.  One way forward is to use an ALTO-specific incremental
> update that may be more efficient, and the second approach is to
> simply use JSON patch.)
> 
> 4. Server-initiated update notifications
> (Jan Seedorf and Enrico Marocco have suggested the use of
> Websockets; HTTP/2.0 may provide some mitigation as well.)
> 
> 5. Extensions to annotate PIDs with properties (e.g., geographical
> locations).
> (Useful as an extension in controlled environments, e.g., VPNs
> where IP addresses are not the only form of identification.
> Some drafts, including draft-roome-alto-pid-properties
> has already started work in this direction.)
> 
> 6. Extensions for cost metrics.
> (Some drafts, including draft-wu-alto-json-te, have started work
> in this direction.)
> 
> 7. An ALTO format for encoding graphs.
> (draft-ietf-alto-protocol already recognizes the need to provide
> topology details that are useful in controlled environments.
> Richard Yang, Greg Bernstein and others have been working on the
> need and use cases for such an encoding.  draft-yang-alto-topology
> is a good start.  Projects like OpenDayLight and NetworkX (Python)
> have JSON models for graph representation.  Some concrete examples
> of how we envision encoding graphs will be useful during list
> discussion.)
> 
> We will like to understand whether the working group believe such
> additional deliverables, if included in an updated charter proposal,
> would allow people to do the extension work that has been repeatedly
> proposed. (Clarification: we are explicitly asking whether people could
> find such an update acceptable. We understand that anyone will have a
> preferred flavor of the above.)
> 
> We are at a point where show of support by whoever is interested is
> essential for moving forward. If it turns out to be positive, Enrico
> and I will subsequently circulate actual text, including milestones, for
> a rechartering request.
> 
> Thanks.
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WG adoption of *-3pdisc and *-ip-based-srv-disc drafts

[Jan Seedorf]

I support the adoption of both documents.

For the lmap use cases, 3rd party discovery may be necessary, e.g. if a web 
service provider want to find out which ALTO server can provide LMAP result for 
a given end user IP address.

 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Sebastian Kiesel
> Sent: Thursday, October 17, 2013 2:05 PM
> To: Enrico Marocco
> Cc: alto@ietf.org
> Subject: Re: [alto] WG adoption of *-3pdisc and *-ip-based-srv-disc drafts
> 
> Dear all,
> 
> On Tue, Oct 15, 2013 at 09:44:54AM +0200, Enrico Marocco wrote:
> > Dear WG participants:
> >
> > we would like to check consensus on the adoption of the following drafts
> > that will complement the server discovery deliverable in the current
> > ALTO WG charter:
> >
> >   + draft-kiesel-alto-ip-based-srv-disc
> >   + draft-kist-alto-3pdisc
> 
> [writing as a co-author of these two drafts]
> 
> Of course I think both drafts are useful and should be adopted, but
> I leave the decision up to our valued chairmen whether to consider/count
> this statement. :)
> 
> 
> 
> [writing as a co-author of RFC 6708 (ALTO requirements)]
> 
> I'd like to bring to your attention that AR-33 (third-party discovery)
> is the only requirement we have documented, for which no WG item
> specification exists so far.
> draft-kist-alto-3pdisc provides a solution for this requirement.
> However, if someone knows another (better?) solution, please share it
> with us now.
> 
> AR-32 (resource consumer initiated ALTO server discovery) is supported
> by draft-ietf-alto-server-discovery-10, which is now in the RFC editor
> queue.  While this draft is definitely uselful in several important
> deployment scenarios, it is not 100% optimal in the light of AR-37.
> This is where draft-kiesel-alto-ip-based-srv-disc fits in.
> 
> Thanks
> Sebastian
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Security problem: DoS attacks via overload

[Jan Seedorf]

Just to second this, I am resending a comment I made a long time ago about DoS 
attacks / too large matrices (cut and paste from my IETF-75 notes):

"Jan Seedorf: has concerns with the workload for ALTO servers caused by queries 
with multiple source network locations, risk of easy DoS attacks, answer: the 
resulting answer matrices can be pre-computed and should not change that 
frequently"

I remember that in that session (IETF-75) we exactly discussed the problem of 
"n(src)*n(dest)" becoming too large, or at least I made that comment ...

 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Diego R. Lopez
> Sent: Thursday, March 21, 2013 1:41 AM
> To: alto@ietf.org
> Subject: Re: [alto] Security problem: DoS attacks via overload
> 
> Hi,
> 
> Since I am in the same situation as Wendy (in terms of being old enough to
> remember when the Internet was small and even when it barely existed) I
> like the idea of the "Request Too Large" error code, that reminds me what a
> LDAP server returns when a search would include more entries than what
> the server configuration allows to be returned.
> 
> And I must say I support the idea of making full cost maps optional. Replacing
> MUST for a SHOULD (and making clear that only the "Request Too Large"
> error is acceptable to not satisfy it) should be enough to avoid the overload
> risk while staying as close as possible to the minimum that makes Sebastian
> feel uneasy...
> 
> Be goode,
> 
> --
> "Esta vez no fallaremos, Doctor Infierno"
> 
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
> 
> e-mail: di...@tid.es
> Tel:+34 913 129 041
> Mobile: +34 682 051 091
> -
> 
> 
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO IETF-86 Side Meeting Info

[Jan Seedorf]

Hi Richard,

Enrico and I can also briefly present our "WebSocket-based server-to-client 
notifications for ALTO" draft (draft-marocco-alto-ws-01).

Can you please add it to the agenda?

Thanks,
Jan 

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of Y.
> Richard Yang
> Sent: Monday, March 11, 2013 11:25 PM
> To: IETF ALTO
> Subject: [alto] ALTO IETF-86 Side Meeting Info
> 
> Dear all,
> 
> Here is the info for the ALTO side meeting. Any suggestions are highly
> welcome!
> 
> Richard Y.
> 
> -
> 
> ALTO IETF-86 Side Meeting
> Time: 8:15 PM - 9:45 PM on Wednesday, Mar. 13, 2013
> Location: Caribbean 7
> Goals: (1) Discuss some remaining key issues for the base protocol; (2)
> Discuss specific changes/extensions to the base protocol to support new
> features and the ordering to take on the work
> 
> - Base protocol to prepare for the meeting on Friday [10 min]
>   Reinaldo Penno/Y. Richard Yang
> 
> - Extensions
> 
>   * VPN (http://datatracker.ietf.org/doc/draft-scharf-alto-vpn-service/) [5
> min]
> Michael Scharf
> 
>   * High bw/topology (http://datatracker.ietf.org/doc/draft-lee-alto-app-net-
> info-exchange/ [5 min]
> Young Lee
> 
>   * Incr update (http://tools.ietf.org/html/draft-schwan-alto-incr-updates-
> 02) [5 min]
> Michael Scharf
> 
>   * General DC resources (http://datatracker.ietf.org/doc/draft-lee-alto-ext-
> dc-resource/) [5 min]
> Young Lee
> 
>   * I2RS (draft-song-alto-i2rs 
> (http://datatracker.ietf.org/doc/draft-song-alto-
> i2rs/) [5 min]
> Haibin Song
> 
> - Discussions [40 min]
> 
> Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] New Draft "ALTO for LMAP"

[Jan Seedorf]

Dear all,

We have submitted a draft that outlines how ALTO could be used to 
export/exploit LMAP measurement results. Comments are very welcome.

- Jan

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, February 18, 2013 3:55 PM
To: enrico.maro...@telecomitalia.it
Cc: v...@bell-labs.com; Jan Seedorf
Subject: New Version Notification for draft-seedorf-lmap-alto-00.txt


A new version of I-D, draft-seedorf-lmap-alto-00.txt
has been successfully submitted by Enrico Marocco and posted to the
IETF repository.

Filename:draft-seedorf-lmap-alto
Revision:00
Title:   ALTO for LMAP
Creation date:   2013-02-18
Group:   Individual Submission
Number of pages: 12
URL: 
http://www.ietf.org/internet-drafts/draft-seedorf-lmap-alto-00.txt
Status:  http://datatracker.ietf.org/doc/draft-seedorf-lmap-alto
Htmlized:http://tools.ietf.org/html/draft-seedorf-lmap-alto-00


Abstract:
   In the context of Large-Scale Measurement of Broadband Performance
   (LMAP), measurment results are currently made available to the public
   either at the finest granularity level (e.g. as a list of results of
   all individual tests), or in a very high level human-readable format
   (e.g. as PDF reports).

   This document argues that there is a need for an intermediate way to
   provide access to large-scale network measurement results, flexible
   enough to enable querying of specific and possibly aggregated data.
   The Application-Layer Traffic Optimization (ALTO) Protocol, defined
   with the goal to provide applications with network information, seems
   a good candidate to fulfill such a role.


  


The IETF Secretariat

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-02.txt

[Jan Seedorf]

Dear all,

I have just submitted a new version of draft-seedorf-cdni-request-routing-alto. 
As before, the draft outlines how ALTO could be used for CDNI request routing, 
in particular for downstream CDN selection. The new version clarifies some 
additional assumptions, refers to some of the latest discussions we have had in 
the footprint/capabilities design team, and also gives some more concrete 
examples on how ALTO network and cost maps would look like and what the design 
choices here are.

Comments are welcome.

See you in Vancouver,

 - Jan

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 16, 2012 4:21 PM
To: Jan Seedorf
Subject: New Version Notification for 
draft-seedorf-cdni-request-routing-alto-02.txt


A new version of I-D, draft-seedorf-cdni-request-routing-alto-02.txt
has been successfully submitted by Jan Seedorf and posted to the
IETF repository.

Filename:draft-seedorf-cdni-request-routing-alto
Revision:02
Title:   CDNI Request Routing with ALTO
Creation date:   2012-07-16
WG ID:   Individual Submission
Number of pages: 20
URL: 
http://www.ietf.org/internet-drafts/draft-seedorf-cdni-request-routing-alto-02.txt
Status:  
http://datatracker.ietf.org/doc/draft-seedorf-cdni-request-routing-alto
Htmlized:
http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-02
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-seedorf-cdni-request-routing-alto-02

Abstract:
   Network Service Providers (NSPs) are currently considering to deploy
   Content Delivery Networks (CDNs) within their networks.  As a
   consequence of this development, there is a need for interconnecting
   these local CDNs.  The necessary interfaces for inter-connecting CDNs
   are currently being defined in the Content Delivery Networks
   Interconnection (CDNI) WG.  This document focusses on the Request
   Routing Interface of CDNI, and more specifically on how the solutions
   currently being defined in the Application Layer Traffic Optimization
   (ALTO) WG can improve CDNI request routing.  The overall intention
   behind this document is to foster discussions (in the CDNI as well as
   in the ALTO WG) regarding if, how, and under what conditions ALTO can
   be useful to optimize CDNI request routing.  As basis for this
   discussion, this document provides concrete examples of how ALTO can
   be integrated within CDNI request routing and in particular in the
   process of selecting a downstream CDN.  The examples in this document
   are based on the use cases and examples currently being discussed in
   the CDNI WG.


  


The IETF Secretariat
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] draft-marocco-alto-next-00

[Jan Seedorf]

Hi Haibin,

> If ALTO provides the information about what contents/apps are
> available on which endpoints/servers, that will make the ALTO server look
> like a huge resource directory, which is hard to manage and should be
> provided by the application themselves.
True, if ALTOext would provide details about all content-IDs etc. But what if 
ALTOext would only provide information about which TYPES/CLASS of content is 
stored at a given endpoint/server, e.g. "videos larger than 1MB for content 
provider xyz.com" or "videos encoded as x from content provider z"?

 - Jan


> -Original Message-
> From: altoext-boun...@ietf.org [mailto:altoext-boun...@ietf.org] On
> Behalf Of Songhaibin
> Sent: Friday, March 02, 2012 8:54 AM
> To: Martin Stiemerling; David Harrington; alto@ietf.org; alto...@ietf.org
> Subject: Re: [altoext] draft-marocco-alto-next-00
> 
> Hi Martin and Dave, I like the discussion. And beyond that, I agree with most
> of the items in the draft except section 3.2.3 about content availability on
> hosts. If ALTO provides the information about what contents/apps are
> available on which endpoints/servers, that will make the ALTO server look
> like a huge resource directory, which is hard to manage and should be
> provided by the application themselves.
> 
> BR,
> -Haibin
> 
> > -Original Message-
> > From: altoext-boun...@ietf.org [mailto:altoext-boun...@ietf.org] On
> Behalf Of
> > Martin Stiemerling
> > Sent: Thursday, March 01, 2012 6:22 PM
> > To: David Harrington; alto@ietf.org; alto...@ietf.org
> > Subject: Re: [altoext] draft-marocco-alto-next-00
> >
> > Hi Dave,
> >
> > >From: altoext-boun...@ietf.org [mailto:altoext-boun...@ietf.org] On
> Behalf
> > >Of David Harrington
> > >Sent: Thursday, February 23, 2012 5:10 PM
> > >To: alto@ietf.org; alto...@ietf.org
> > >Subject: [altoext] draft-marocco-alto-next-00
> > >
> > >Hi,
> > >
> > >AD-hat-off ...
> > >
> > >I am not very convinced this is a set of problems that need ALTO solutions.
> > >
> > >When dealing with P2P scenarios, ALTO is important because endpoints
> for a
> > >large amount of P2P are "unmanaged" - they are typically home users
> sharing
> > >files with other home users. Home users typically do not use/monitor
> > >protocols such as BGP, ISIS, SNMP, Conex, ECN. Frequently consumer
> > equipment
> > >doesn't make these protocols available/accessible to end-users.
> >
> > One additional thing to that:
> > Home users or application developers also potentially do not understand
> the
> > information provided by BGP, ISIS, SNMP, etc.
> >
> > >
> > >The information about the network, like server load, link status,
> bandwidth
> > >availability, is not something the network providers necessarily want to
> > >share. Network operators should be concerned about sharing with
> anonymous
> > >users, who might well be interested in maliciously attacking the network
> > >environment.
> >
> > This is understood in the ALTO WG and documented in Section 12 of
> > draft-ietf-alto-protocol-10. ALTO was seen as a good way of providing
> > information to applications, but still not telling everything about the
> network
> > infrastructure.
> >
> > >
> > >Data centers and CDNs typically are "managed" environments, and the
> > >file-sharing/load-balancing/congestion control protocols are for use within
> > >the administrative domain by the operators of the data centers or CDNs
> (or
> > >between "peered" environments, where there is a certain level of trust).
> >
> > I disagree that CDNs are mainly operating in managed environments. The
> CDN
> > system with its components, e.g., DNS server, caches, etc, is indeed
> operating in
> > a managed environment. However, all communication between the CDN
> caches
> > and the hosts using the services provided by the CDN are not in a managed
> > environment, i.e., they are operating over the Internet.
> >
> > Peered environments give a certain level of business relationship, but I'm
> not
> > sure that there is a lot of trust between the traditional CDN operators and
> the
> > local network operators.
> >
> > >These environments typically have access to protocols such as SNMP and
> BGP,
> > >and how the network is "tweaked" to accommodate dynamic traffics
> patterns is
> > >the business of the network provider, using specialty applications to adapt
> > >the network at the lower layers. Operators and their OAM protocols
> monitor
> >
> > CDNs do have access to BGP, but a global CDN does definitely not have
> access to
> > the local networks' SNMP data. Even for operator hosted CDNs, it may not
> the
> > case that the CDN operator is allowed to access SNMP on the network
> elements,
> > as this can two completely different departments (i.e., for regulatory
> reasons or
> > business reasons).
> >
> > I know operators who want to have a better "linkage" between them and
> the
> > CDNs around them, e.g., potentially going beyond what BGP is offering (to
> be
> > explored). One of doing this could 

[alto] Draft submitted on ALTO for CDNi request routing

[Jan Seedorf]

CDNi folks, ALTO folks,

I have just submitted a new draft which discusses how ALTO could help in CDNi 
request routing:

Abstract:
"... This document focusses on the Request Routing Interface of CDNi, and more 
specifically on how the solutions currently being defined in the Application 
Layer Traffic Optimization (ALTO) WG can improve CDNi request routing.  The 
overall intention behind this document is to foster discussions (in the CDNi as 
well as in the ALTO WG) regarding a) if, b) how, and c) under what conditions 
ALTO can be useful to optimize CDNi request routing.  As basis for this 
discussion, this document provides concrete examples of how ALTO can be 
integrated within CDNi request routing.  The examples in this   document are 
based on the use cases and examples currently being discussed in the CDNi WG."

http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00.txt

Comments (from CDNi WG and ALTO WG) are welcome,


-  Jan
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software

[Jan Seedorf]

Dear Henry, all,

I apologize for abusing the mailing lists.

Many IETF people had told me individually that they are highly interested in 
our workshop but cannot attend in person. I had received many emails with 
questions on how to access workshop material after the event. Thus, I thought 
it is of interest to this community that we are streaming the workshop live 
with P2P software and everybody can join the P2P swarm to watch the talks.

Sorry if my mail was perceived as spam,

 - Jan

> -Original Message-
> From: Henry Sinnreich [mailto:henry.sinnre...@gmail.com]
> Sent: Dienstag, 18. Januar 2011 18:24
> To: Jan Seedorf; p2...@irtf.org; P2PSIP WG; p...@ietf.org; 'alto';
> dec...@ietf.org
> Subject: Re: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P
> software
> 
> This spam is highly unwelcome.
> Also quite surprising, since your spam has already been called out on
> another list.
> 
> Thanks, Henry
> 
> 
> On 1/18/11 4:30 AM, "Jan Seedorf"  wrote:
> 
> > P2P folks at IETF,
> >
> > To help people interested in the P2P-TV workshop we are hosting,
> > the NAPA-WINE project's final workshop will be *broadcasted live*
> > with the P2P Live Streaming Software developed by the NAPA-WINE project.
> >
> > The workshop opens on Thursday 20th January at 2.30PM CET and closes
> > on Friday 21th January afternoon at 6.00PM CET.
> > Recordings of the workshop will be made available from the project web site
> > few days after the event too.
> >
> > For people interested in following the workshop/talks live
> > via P2P video stream, we have prepared a page with Quick-Start
> > instructions on how to download, install, and use the software
> > to follow the event live. If you are interested, please go to
> >
> > http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive
> >
> > If you have any questions regarding the use of the software or following
> > the final workshop live with it, please use the mailing list
> > (napal...@tlc.polito.it).
> >
> > A demo activity of the software is scheduled at 5.30PM (and yes! you
> > will be part of the demo if you join the channel!)
> >
> > *Workshop Program*
> > The final NAPA-WINE workshop is intended as an informal forum for lively
> > discussions on current and future trends in peer-to-peer live streaming. The
> > program comprises four talks presenting the main NAPA-WINE achievements (and
> a
> > demo of NAPA-WINE's network-aware P2P live streaming system) as well as nine
> > talks from external highly qualified researchers from both academia and
> > industry, providing a broad and articulated perspective on the main
> challenges
> > and solutions on the topic. There will be external presentations provided by
> > (see http://www.napa-wine.eu/workshop/program.html for agenda details):
> >
> > - Presentations from other on-going  European projects on P2P-TV/CDN:
> >   * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL,
> GB)
> >   * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT)
> >   * P2P-NEXT (Raul Jimenez, KTH, SE)
> > - Presentations from the industrial world (the operator/content provider
> > vision):
> >   * Nikolaos Laoutaris,  Telefonica Research, ES
> >   * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT
> > - Presentations from academia (technical challenges)
> >   * Ernst Biersack, Eurecom, FR
> >   * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE
> >   * Yong Liu, Polytechnic Institute of NYU, US
> >   * Victoria Fodor, Gyorgy Dan, KTH, SE
> >
> > For further workshop program details, please see
> > http://www.napa-wine.eu/workshop/
> >
> >  - Jan
> >
> > 
> > Jan Seedorf
> > Senior Researcher
> > NEC Europe Ltd., NEC Laboratories Europe, Network Division
> > Kurfuerstenanlage 36, D-69115 Heidelberg
> > Tel. +49 (0)6221 4342-221
> > Fax: +49 (0)6221 4342-155
> > e-mail:  jan.seed...@neclab.eu
> > 
> > NEC Europe Limited Registered Office: NEC House,
> > 1 Victoria Road, London W3 6BL Registered in England 2832014
> >
> >
> > ___
> > decade mailing list
> > dec...@ietf.org
> > https://www.ietf.org/mailman/listinfo/decade
> 

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Live streaming of NAPA-WINE P2P-TV workshop with P2P software

[Jan Seedorf]

P2P folks at IETF,

To help people interested in the P2P-TV workshop we are hosting,
the NAPA-WINE project's final workshop will be *broadcasted live*
with the P2P Live Streaming Software developed by the NAPA-WINE project.

The workshop opens on Thursday 20th January at 2.30PM CET and closes
on Friday 21th January afternoon at 6.00PM CET.
Recordings of the workshop will be made available from the project web site
few days after the event too.

For people interested in following the workshop/talks live
via P2P video stream, we have prepared a page with Quick-Start
instructions on how to download, install, and use the software
to follow the event live. If you are interested, please go to

http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive

If you have any questions regarding the use of the software or following
the final workshop live with it, please use the mailing list 
(napal...@tlc.polito.it).

A demo activity of the software is scheduled at 5.30PM (and yes! you
will be part of the demo if you join the channel!) 

*Workshop Program* 
The final NAPA-WINE workshop is intended as an informal forum for lively
discussions on current and future trends in peer-to-peer live streaming. The
program comprises four talks presenting the main NAPA-WINE achievements (and a
demo of NAPA-WINE's network-aware P2P live streaming system) as well as nine
talks from external highly qualified researchers from both academia and
industry, providing a broad and articulated perspective on the main challenges
and solutions on the topic. There will be external presentations provided by
(see http://www.napa-wine.eu/workshop/program.html for agenda details):

- Presentations from other on-going  European projects on P2P-TV/CDN:
  * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL, GB)
  * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT)
  * P2P-NEXT (Raul Jimenez, KTH, SE)
- Presentations from the industrial world (the operator/content provider 
vision):
  * Nikolaos Laoutaris,  Telefonica Research, ES
  * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT
- Presentations from academia (technical challenges)
  * Ernst Biersack, Eurecom, FR
  * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE
  * Yong Liu, Polytechnic Institute of NYU, US
  * Victoria Fodor, Gyorgy Dan, KTH, SE

For further workshop program details, please see 
http://www.napa-wine.eu/workshop/

 - Jan

========
Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division 
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu

NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Call for Participation: International Workshop on P2P-TV (no registration fee)

[Jan Seedorf]

Folks,

We (the EU project NAPA-WINE) are organizing an international workshop on 
P2P-TV without any registration fee, anybody interested is welcome to attend 
(please register though at the link below if you do intend to come so that we 
can plan for the right number of attendees). Please find details below in the 
call for participation for the workshop.

  - Jan

*

Call for Participation
  International Workshop on P2P-TV
(organised by the NAPA-WINE Project)

 Torino, Italy, January 20-21, 2011
  http://www.napa-wine.eu/workshop/


*Overview*
TV services over the Internet can be provided either exploiting IP multicast
functionalities or relying on a pure end-to-end (P2P) approach. The P2P approach
has been successfully exploited to overcome limitations of IP-based solutions
(like reliance on the network infrastructure controlled by a single broadband
operator) and can potentially offer a scalable planetary infrastructure.
Recently, several P2P-TV systems started to show up, with the last generation
offering High Quality TV (P2P-HQTV) systems, providing a ubiquitous access to
the service. These same potentialities of P2P-TV systems constitute a worry for
network carriers since the traffic they generate may potentially grow without
control, causing a degradation of quality of service perceived by Internet users
or even the network collapse (and the consequent failure of the P2P-HQTV service
itself!).

*Workshop Program* 
The final NAPA-WINE workshop is intended as an informal forum for lively
discussions on current and future trends in peer-to-peer live streaming. The
program comprises four talks presenting the main NAPA-WINE achievements (and a
demo of NAPA-WINE's network-aware P2P live streaming system) as well as nine
talks from external highly qualified researchers from both academia and
industry, providing a broad and articulated perspective on the main challenges
and solutions on the topic. There will be external presentations provided by
(see http://www.napa-wine.eu/workshop/program.html for agenda details):

- Presentations from other on-going  European projects on P2P-TV/CDN:
  * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL, GB)
  * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT)
  * P2P-NEXT (Raul Jimenez, KTH, SE)
- Presentations from the industrial world (the operator/content provider 
vision):
  * Nikolaos Laoutaris,  Telefonica Research, ES
  * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT
- Presentations from academia (technical challenges)
  * Ernst Biersack, Eurecom, FR
  * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE
  * Yong Liu, Polytechnic Institute of NYU, US
  * Victoria Fodor, Gyorgy Dan, KTH, SE

*Logistics*
Location: The workshop will take place at VALENTINO CASTLE (Castello del
Valentino), Viale Mattioli 39, 10125 Torino, Italy. Valentino Castle campus is
situated quite near the main railway station of Porta Nuova, in an area
characterized by open green spaces. It is in the heart of Valentino Park with a
wonderful view of the Po River. More details on getting to the workshop are
available at http://www.napa-wine.eu/workshop/location.html.

*Schedule*
 - start: Thursday, January 20th, 2011, 2.00 p.m.
 - end:   Friday,   January 21st, 2011, 5.30 p.m.
A social dinner will be offered by the NAPA-WINE project on Thursday evening.

*Registration*
There is *no* *registration* *fee* to participate in the workshop. However,
participants are kindly invited to register their attendance by January 10th,
2011, at http://www.napa-wine.eu/workshop/registration.html. People that will
not register may not be granted access due to seat limitations.

***

====
Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division 
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@neclab.eu

NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Security section of draft-penno-alto-protocol-03

[Jan Seedorf]

Dear Yan,

> After reading this draft, I feel that the entity is well designed, and
> the functions are enhanced. However, conventional cons seem still
> exist, especially some aspects on workload and privacy need to be
> clarified, the method to authenticate too many information may increase
> workload significantly.
My point was that I think the final draft needs to discuss the security issues 
in much more detail and state explicitly how they are addressed with the 
protocol, and if not what other solution are out there and could in principle 
help.

 - Jan




> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Wang Yan
> Sent: Donnerstag, 13. August 2009 04:51
> To: Jan Seedorf; alto
> Subject: Re: [alto] Security section of draft-penno-alto-protocol-03
> 
> Hi, Jan
> 
> > -- "An ALTO Server may optionally use authentication and encryption
> to
> >   protect ALTO information.  Authentication and encryption may be
> >   provided using HTTP Basic or Digest Authentication and/or SSL/TLS."
> > --> I think this text is not specific enough. What needs to be
> authenticated are three things: a) the identity of the server, b) the
> identity of the client, and c) the ALTO information itself. TLS is a
> solution for a) and b), but for c) the ALTO information needs to be
> signed by other means, and not only on transport from client to server.
> Another thing the WG should discuss: is encryption necessary? Indeed,
> an ALTO-server should authenticate clients but the information it
> provides should not be confidential, especially if redistribution is
> specifically allowed.
> >
> > -- As I was mentioning during the ALTO session in Stockholm, I see
> the risk of Denial-of-Service attacks on ALTO servers. Even if the ALTO
> server has some pre-computed cost maps, an attacker could easily stress
> an ALTO server by simply querying all potential permutations of source-
> lists and destinations-lists. It is unlikely that the ALTO-server has
> all of them pre-computed. In security, it is always seen problematic
> (from a DoS perspective) if simple/small messages can generate large
> workload at a server. I think this is the case for ALTO if a Path
> Rating query has a list of multiple Source Network Locations.
> >
> > -- I think the security section has only very general text on privacy
> issues. This is strange since the draft says: "Two key design
> objectives of the ALTO Protocol are simplicity and extensibility.  At
> the same time, it introduces additional techniques to address potential
> scalability and privacy issues." It would be nice to discuss these
> issues in the concrete scope of the proposed ALTO-protocol.
> >
> > Again, I know the authors were focusing on the merge, but I hope they
> agree that the security section needs much more work. I felt like
> giving it a start with some comments.
> 
> Agreed.
> 
> I think currently it is a good idea to combine most good solutions
> together, after all they are basically to solve one problem. However,
> since each solution has its own pros and cons,  good combinations can
> make them complementary to each other and improve the advantages of
> protocol, whereas bad combinations may not only increase the load of
> server but also preserve the disadvantages of all the solutions, and
> increase the risk of privacy at the same time.
> 
> After reading this draft, I feel that the entity is well designed, and
> the functions are enhanced. However, conventional cons seem still
> exist, especially some aspects on workload and privacy need to be
> clarified, the method to authenticate too many information may increase
> workload significantly.
> 
> 
> Regards
> Yan
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-00]

[Jan Seedorf]

Dear Yingjie,

> I think "Redistribution" should not be unlimited.
How do you want to limit redistribution in practice, i.e., how do you want to 
enforce such a limitation?

> Second, redistributed information must include accurate ALTO SERVER
> INFORMATION, e.g. network position or name, and what kind of
> information it
> is, so that client can judge the usage of the information.
> Last but not least, client must cognize his ALTO SERVER INFORMATION and
> share a unified information description language among all clients, at
> least
> those in one application swarm.
I agree, but in addition it is also very important that the redistributed ALTO 
information includes the input parameters which where the basis for generating 
the ALTO information.


> Instead of an overall trusted third party, a dedicated CA for a
> particular
> network position, neither too small nor too big, will work.
> Applications can
> make their clients cognize the dedicated CA as they notice clients
> about
> dedicated ALTO servers.
Yes, that can work, but especially if you consider mobility of clients it will 
not always work.

Also, currently the WG is discussing ALTO discovery. That means that ALTO 
clients most probably will not have the location of ALTO servers "hardcoded" in 
their implementation. However, to boostrap a CA hierarchy of trust, the public 
key of a Root-CA needs to be available to the client. I do not believe in PKI 
set-up by users nor certificate management by users (think of certificate error 
messages in today's web-browsers, which btw have a certificate of a Root-CA 
hardcoded in their implementation).

All I am saying is that it works fine in theory but is not so easy in 
practice...

 - Jan


> -Original Message-
> From: Y.J. Gu [mailto:guying...@huawei.com]
> Sent: Donnerstag, 13. August 2009 05:56
> To: Jan Seedorf; 'alto'
> Subject: RE: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-
> redist-00]
> 
> Hi Jan,
> See in line pls.
> 
> Regards
> 
> Yingjie Gu
> 
> 
> 
> > -Original Message-
> > From: Jan Seedorf [mailto:jan.seed...@nw.neclab.eu]
> > Sent: Wednesday, August 12, 2009 11:15 PM
> > To: Y.J. Gu; alto
> > Subject: RE: [alto] [ALTO] Comments on
> > [draft-stiemerling-alto-info-redist-00]
> >
> > Dear Yingjie,
> >
> > I think the problem of redistributed ALTO-information is not
> > so easy, some comments below.
> 
> > Agreed, there may be certain use-cases where redistribution
> > may not be problematic. But consider the case where certain
> > information provided by an ALTO-server is _relative_ to that
> > ALTO-server's location in the network. If such information
> > gets redistributed, an ALTO-client not being aware of the
> > original ALTO-server's location may misinterpret this
> > information. In other words, by redistributing guidance
> > information, its original semantic might be disguised. I
> > think this is the problem being addressed in Martin's draft
> > and specifically in the quote above.
> >
> 
> I think "Redistribution" should not be unlimited.
> First of all, not all information is redistributed.
> Second, redistributed information must include accurate ALTO SERVER
> INFORMATION, e.g. network position or name, and what kind of
> information it
> is, so that client can judge the usage of the information.
> Last but not least, client must cognize his ALTO SERVER INFORMATION and
> share a unified information description language among all clients, at
> least
> those in one application swarm.
> Richard Alimi gave excellent examples in his email. Of course, there
> maybe
> other methods.
> By this mean, client can find suitable redistributed information.
> 
> > Indeed, a CA-hierarchy is the technical solution. However,
> > practically it is not always the case that two hosts on the
> > Internet share a trusted third party, and certainly there is
> > no overall Internet-wide CA hierarchy trusted by all hosts.
> > In P2PSIP-RELOAD, the assumption is that there is an
> > enrollment server, i.e., a certificate authority which
> > certifies identities in the P2P-network (DHT). In other
> > words, any peer who wants to join the P2PSIP network has to
> > enroll with this identity certification service. I do not
> > think that is a reasonable assumption for ALTO and I think
> > this was the point in the quote above.
> >
> >  - Jan
> 
> Instead of an overall trusted third party, a dedicated CA for a
> particular
> network position, neither too small nor too big, will work.
> Applications can
> make their clients cognize the dedicated CA as they notice clients
> about
> dedicated ALTO servers.

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [ALTO] Comments on[draft-stiemerling-alto-info-redist-00]

[Jan Seedorf]

Hi Richard,

> The redistributed ALTO information should indicate the ALTO Server from
> which
> it originated, and the parameters that were supplied to request that
> information.  
Right, this is important to prevent misinterpretation of redistributed ALTO 
information.

> For example, when looking at a listing of the available
> ALTO
> information, an peer can look for the ALTO server it would have
> contacted
> otherwise (perhaps, hostname:port of the ALTO server), and grab the
> ALTO
> information pertaining to that server.
> 
> This "listing of available ALTO information" could be posted on a
> public
> website (available as direct downloads, torrent files, etc).  Another
> option
> would be to distribute via a DHT (a la Vuze's Distributed Tracker)
> where the
> key is hash("alto:::networkmap").  Something similar
> could be
> used to request the full cost map:
> hash("alto:::costmap:")
> 
> To redistribute only a portion of the cost map (e.g., a row of the
> matrix from
> the perspective of a single PID), then the map could be stored at
> hash("alto:::costmap::").

Sorry, I am not completely following you: are you saying that such a "listing 
of available ALTO information" is redistributed ALTO information posted on a 
website? So someone could program an ALTO-grab-all-crawl-bot and post all 
information retrieved on a website, right? Clearly nobody can prevent something 
like that, that is why it is important that ALTO information is not only 
authenticated and its integrity protected (i.e., signed), but also that the 
digital signature contains an expiration time and the complete input variables 
for the generated ALTO information. Still, what if an ALTO server realizes it 
was misconfigured or something changes unexpectedly, than the ALTO server has 
no way of controlling its already redistributed, now "wrong" information. What 
do you think?

 - Jan


> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Richard Alimi
> Sent: Mittwoch, 12. August 2009 17:43
> To: alto@ietf.org
> Cc: Jan Seedorf
> Subject: Re: [alto] [ALTO] Comments on[draft-stiemerling-alto-info-
> redist-00]
> 
> Hi Jan,
> 
> > > --  "However, there is no mean for the peers to verify whether the
> > > information provided is actually intended
> > >for their usage nor if the information is actually accurate at
> their
> > > current topological position in the Internet "
> > >
> > > Surely, it's very important to verify the usage and the origination
> of
> > > the
> > > redistributed information.
> > > I don't think accurate information needs to be redistributed.
> > > Actually, there are kinds of general information that are suitable
> and
> > > helpful to be redistributed.
> > > E.g. kinds of cost between a particular PID and other PIDs is
> useful to
> > > all
> > > the peers in the particular PID.
> > > What we should do is to guarantee that general information is
> > > redistributed
> > > within the PID area(maybe multicast) or to guarantee that peer only
> > > request
> > > its PID general information.
> >
> > Agreed, there may be certain use-cases where redistribution may not
> be
> > problematic. But consider the case where certain information provided
> by an
> > ALTO-server is _relative_ to that ALTO-server's location in the
> network. If
> > such information gets redistributed, an ALTO-client not being aware
> of the
> > original ALTO-server's location may misinterpret this information. In
> other
> > words, by redistributing guidance information, its original semantic
> might
> > be disguised. I think this is the problem being addressed in Martin's
> draft
> > and specifically in the quote above.
> 
> The redistributed ALTO information should indicate the ALTO Server from
> which
> it originated, and the parameters that were supplied to request that
> information.  For example, when looking at a listing of the available
> ALTO
> information, an peer can look for the ALTO server it would have
> contacted
> otherwise (perhaps, hostname:port of the ALTO server), and grab the
> ALTO
> information pertaining to that server.
> 
> This "listing of available ALTO information" could be posted on a
> public
> website (available as direct downloads, torrent files, etc).  Another
> option
> would be to distribute via a DHT (a la Vuze's Distributed Tracker)
> where the
> key is hash("alto:::networkmap").  Something similar
> cou

[alto] Security section of draft-penno-alto-protocol-03

[Jan Seedorf]

Dear all,

I understand that prior to IETF-75 the authors of draft-penno-alto-protocol-03 
where busy with merging the protocols. But I would like to point out that the 
security section is still far from done. Some points that immediately come to 
mind are:

-- 10.4.: "To fulfill these requirements, ALTO Information meant to be
   redistributable contains a digital signature which includes a hash of
   the ALTO information encrypted by the ALTO Server's private key."
--> replace "encrypted by the ALTO Server's private key" with "signed by the 
ALTO Server's private key" [in asymmetric cryptography, you either _decrypt_ or 
_sign_ with a private key]

-- 10.4.  ALTO Information Redistribution --> you basically suggest to have the 
ALTO-server sign information it provides. While that is certainly a good idea, 
the problem of ALTO information redistribution may be more sophisticated. 
Martin wrote a draft on some potential issues 
(draft-stiemerling-alto-info-redist-00). 

-- "An ALTO Server may optionally use authentication and encryption to
   protect ALTO information.  Authentication and encryption may be
   provided using HTTP Basic or Digest Authentication and/or SSL/TLS."
--> I think this text is not specific enough. What needs to be authenticated 
are three things: a) the identity of the server, b) the identity of the client, 
and c) the ALTO information itself. TLS is a solution for a) and b), but for c) 
the ALTO information needs to be signed by other means, and not only on 
transport from client to server. Another thing the WG should discuss: is 
encryption necessary? Indeed, an ALTO-server should authenticate clients but 
the information it provides should not be confidential, especially if 
redistribution is specifically allowed.

-- As I was mentioning during the ALTO session in Stockholm, I see the risk of 
Denial-of-Service attacks on ALTO servers. Even if the ALTO server has some 
pre-computed cost maps, an attacker could easily stress an ALTO server by 
simply querying all potential permutations of source-lists and 
destinations-lists. It is unlikely that the ALTO-server has all of them 
pre-computed. In security, it is always seen problematic (from a DoS 
perspective) if simple/small messages can generate large workload at a server. 
I think this is the case for ALTO if a Path Rating query has a list of multiple 
Source Network Locations.

-- I think the security section has only very general text on privacy issues. 
This is strange since the draft says: "Two key design objectives of the ALTO 
Protocol are simplicity and extensibility.  At the same time, it introduces 
additional techniques to address potential scalability and privacy issues." It 
would be nice to discuss these issues in the concrete scope of the proposed 
ALTO-protocol.

Again, I know the authors were focusing on the merge, but I hope they agree 
that the security section needs much more work. I felt like giving it a start 
with some comments.

 - Jan


Jan Seedorf
Research Scientist
NEC Europe Ltd., NEC Laboratories Europe, Network Division  
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@nw.neclab.eu 

NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-00]

[Jan Seedorf]

Dear Yingjie,

I think the problem of redistributed ALTO-information is not so easy, some 
comments below.

> --  "However, there is no mean for the peers to verify whether the
> information provided is actually intended
>for their usage nor if the information is actually accurate at their
> current topological position in the Internet "
>
> Surely, it's very important to verify the usage and the origination of
> the
> redistributed information.
> I don't think accurate information needs to be redistributed.
> Actually, there are kinds of general information that are suitable and
> helpful to be redistributed.
> E.g. kinds of cost between a particular PID and other PIDs is useful to
> all
> the peers in the particular PID.
> What we should do is to guarantee that general information is
> redistributed
> within the PID area(maybe multicast) or to guarantee that peer only
> request
> its PID general information.
Agreed, there may be certain use-cases where redistribution may not be 
problematic. But consider the case where certain information provided by an 
ALTO-server is _relative_ to that ALTO-server's location in the network. If 
such information gets redistributed, an ALTO-client not being aware of the 
original ALTO-server's location may misinterpret this information. In other 
words, by redistributing guidance information, its original semantic might be 
disguised. I think this is the problem being addressed in Martin's draft and 
specifically in the quote above.


> ---"First of all does this require public/private key pair, where the
> public
> key is known to each peer and a trusted third party is required.  These
> requirements are possible to be fulfilled in certain deployments but
> are not
> in the general Internet deployment case, which in turn limits the
> applicability of this protocol.  Second, the receiving peer needs to
> contact
> the ALTO server at least once to obtain the public key part, or it does
> need
> to contact another server that provides the public key pair."
> 
> First, Redistribution can be an optional part of the protocol, ALTO
> server
> can decide whether redistribution is adopted according to internet
> environment. Second, peer can contact CA, instead of ALTO server, to
> obtain
> a public key. In P2PSIP-reload, each peer owns a certificate and every
> peer
> can contact the CA to authenticate the certificate of other peer.
> Reload
> regards this an acceptable workload to CA. I think the frequence of
> obtaining public key from ALTO server is much fewer than the
> authentication
> in Reload. So that may be not a probolem.
> Whatever, the real workload depends on how we design the redistribution
> mechanism.
Indeed, a CA-hierarchy is the technical solution. However, practically it is 
not always the case that two hosts on the Internet share a trusted third party, 
and certainly there is no overall Internet-wide CA hierarchy trusted by all 
hosts. In P2PSIP-RELOAD, the assumption is that there is an enrollment server, 
i.e., a certificate authority which certifies identities in the P2P-network 
(DHT). In other words, any peer who wants to join the P2PSIP network has to 
enroll with this identity certification service. I do not think that is a 
reasonable assumption for ALTO and I think this was the point in the quote 
above.

 - Jan


 


> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Y.J. Gu
> Sent: Mittwoch, 12. August 2009 11:52
> To: 'alto'
> Subject: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-
> 00]
> 
> I'm very glad that at last someone notice redistribution.
> 
> I'm not totally agree with some opinions in the draft.
> 
> --  "However, there is no mean for the peers to verify whether the
> information provided is actually intended
>for their usage nor if the information is actually accurate at their
> current topological position in the Internet "
> 
> Surely, it's very important to verify the usage and the origination of
> the
> redistributed information.
> I don't think accurate information needs to be redistributed.
> Actually, there are kinds of general information that are suitable and
> helpful to be redistributed.
> E.g. kinds of cost between a particular PID and other PIDs is useful to
> all
> the peers in the particular PID.
> What we should do is to guarantee that general information is
> redistributed
> within the PID area(maybe multicast) or to guarantee that peer only
> request
> its PID general information.
> 
> ---"First of all does this require public/private key pair, where the
> public
> key is known to each peer and a trusted third party is required.  These
> requirements are possible to be fulfilled in certain deployments but
> are not
> in the general Internet deployment case, which in turn limits the
> applicability of this protocol.  Second, the receiving peer needs to
> contact
> the ALTO server at least once to obtain the public key part, or it does
> ne

[alto] FW: WGLC: draft-ietf-alto-problem-statement-01

[Jan Seedorf]

Richard,

I forgot one important thing: Thanks for the extensive and good comments! 
Having addressed them, we believe the draft is now in much better shape and 
many things are clearer.

See you in Stockholm,

 - Jan

-Original Message-
From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of Jan 
Seedorf
Sent: Freitag, 3. Juli 2009 17:04
To: Y. Richard Yang; alto@ietf.org
Subject: Re: [alto] WGLC: draft-ietf-alto-problem-statement-01

Dear Richard, ALTO folks,

we have discussed the comments received from Richard for the WGLC of 
"draft-ietf-alto-problem-statement-01" among the editors and addressed them 
accordingly. I have just submitted the new -02 version of the draft. For seeing 
how we addressed the comments please produce a diff from the -01 version and 
compare with the comments from Richard below.

Please check (by the end of next week, July 10th) that we addressed all 
comments and provide feedback on this list otherwise.

 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Y. Richard Yang
> Sent: Sonntag, 7. Juni 2009 06:18
> To: alto@ietf.org
> Subject: Re: [alto] WGLC: draft-ietf-alto-problem-statement-01
> 
> Hi Jan, Eric, Enrico, and Vijay,
> 
> Thanks for the work on the problem statement document!
> 
> Below are some comments for the version at
> (http://www.ietf.org/internet-drafts/draft-ietf-alto-problem-statement-
> 01.txt):
> 
> Richard
> 
> ==
> There are a couple places where I marked with **. These are more
> important.
> 
> - Both abstract and Introduction have this sentence: "Peer-to-peer
>   applications, such as file sharing, real-time communication, and live
>   media streaming ..." It is clear that VoD P2P streaming is becoming
> much
>   more popular than live. For example, if you check PPLive/UUSee, you
> will
>   see a few hundres live streaming channels, but a lot more VoD
> channels.
>   How about changing the sentence to " such as file sharing, real-time
>   communications, live and on-demand media streaming ..."
> 
>   Another nit is the word "real-time communication". Is voice/video
>   conferencing more explicit?
> 
> - Abstract: "direct peer-to-peer connections". Is the word "direct"
> necessary?
> 
> - Abstract: "This document describes problems related to optimizing
>   traffic generated by peer-to-peer applications and associated issues
>   such optimizations raise in the use of network-layer information."
> 
> This sentence is a bit long and may parse in different ways. For
> example, for the first "problems", it is not clear the "problems"
> are
> caused by not optimizing or optimizing in the wrong way. It may be
> helpful to revise the sentence a bit.
> 
> ** Abstract: "may lead to suboptimal choices" and "to optimizing
> traffic";
>   in the text, it uses the word "best" in many places. I know this is
>   consistent with the working group name (this is a reason I do not
> like
>   the working group name :-( But on the other hand, the charter is
> trying
>   to achieve better than random, which may not be "optimizing", may be
>   suboptimal, and may not be the best. I feel that it is necessary to
> go
>   over the document to address this issue. What do you think?
> 
> - Page 1: "resources[WWW.wired.fuel]" need a space before [
> 
> - Section 1.1 first paragraph: "Different from the client/server
>   architecture, P2P applications ..." architecture and applications do
> not
>   match.  A suggestion is to either change architecture to applications
>   or applications to architecture.
> 
> - Section 1.1 second paragraph: "One advantage of P2P systems ..." This
>   time it uses the word systems. So we have P2P systems, P2P
> architecture,
>   and P2P applications. It may be necessary to make sure they are used
> in
>   a consistent way. I will not point out this later. I feel that the
> word
>   systems should be architecture here. What do you think?
> 
> - Section 1.1 second paragraph: "select among available instances": the
>   preceding sentence uses replicas not instances.
> 
> - Section 1.1 second paragraph: "deduce from empirical measurements".
> How
>   about "deduce from partial observations"?
> 
> - Section 1.1 second paragraph: "For example, one popular metric is an
>   estimation of round-trip time." to be consistent with the following
>   sentence, how about
> 
> "For example, one peer selection algorithm is based
> only on the measurements during init

Re: [alto] WGLC: draft-ietf-alto-problem-statement-01

[Jan Seedorf]

Dear Richard, ALTO folks,

we have discussed the comments received from Richard for the WGLC of 
"draft-ietf-alto-problem-statement-01" among the editors and addressed them 
accordingly. I have just submitted the new -02 version of the draft. For seeing 
how we addressed the comments please produce a diff from the -01 version and 
compare with the comments from Richard below.

Please check (by the end of next week, July 10th) that we addressed all 
comments and provide feedback on this list otherwise.

 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Y. Richard Yang
> Sent: Sonntag, 7. Juni 2009 06:18
> To: alto@ietf.org
> Subject: Re: [alto] WGLC: draft-ietf-alto-problem-statement-01
> 
> Hi Jan, Eric, Enrico, and Vijay,
> 
> Thanks for the work on the problem statement document!
> 
> Below are some comments for the version at
> (http://www.ietf.org/internet-drafts/draft-ietf-alto-problem-statement-
> 01.txt):
> 
> Richard
> 
> ==
> There are a couple places where I marked with **. These are more
> important.
> 
> - Both abstract and Introduction have this sentence: "Peer-to-peer
>   applications, such as file sharing, real-time communication, and live
>   media streaming ..." It is clear that VoD P2P streaming is becoming
> much
>   more popular than live. For example, if you check PPLive/UUSee, you
> will
>   see a few hundres live streaming channels, but a lot more VoD
> channels.
>   How about changing the sentence to " such as file sharing, real-time
>   communications, live and on-demand media streaming ..."
> 
>   Another nit is the word "real-time communication". Is voice/video
>   conferencing more explicit?
> 
> - Abstract: "direct peer-to-peer connections". Is the word "direct"
> necessary?
> 
> - Abstract: "This document describes problems related to optimizing
>   traffic generated by peer-to-peer applications and associated issues
>   such optimizations raise in the use of network-layer information."
> 
> This sentence is a bit long and may parse in different ways. For
> example, for the first "problems", it is not clear the "problems"
> are
> caused by not optimizing or optimizing in the wrong way. It may be
> helpful to revise the sentence a bit.
> 
> ** Abstract: "may lead to suboptimal choices" and "to optimizing
> traffic";
>   in the text, it uses the word "best" in many places. I know this is
>   consistent with the working group name (this is a reason I do not
> like
>   the working group name :-( But on the other hand, the charter is
> trying
>   to achieve better than random, which may not be "optimizing", may be
>   suboptimal, and may not be the best. I feel that it is necessary to
> go
>   over the document to address this issue. What do you think?
> 
> - Page 1: "resources[WWW.wired.fuel]" need a space before [
> 
> - Section 1.1 first paragraph: "Different from the client/server
>   architecture, P2P applications ..." architecture and applications do
> not
>   match.  A suggestion is to either change architecture to applications
>   or applications to architecture.
> 
> - Section 1.1 second paragraph: "One advantage of P2P systems ..." This
>   time it uses the word systems. So we have P2P systems, P2P
> architecture,
>   and P2P applications. It may be necessary to make sure they are used
> in
>   a consistent way. I will not point out this later. I feel that the
> word
>   systems should be architecture here. What do you think?
> 
> - Section 1.1 second paragraph: "select among available instances": the
>   preceding sentence uses replicas not instances.
> 
> - Section 1.1 second paragraph: "deduce from empirical measurements".
> How
>   about "deduce from partial observations"?
> 
> - Section 1.1 second paragraph: "For example, one popular metric is an
>   estimation of round-trip time." to be consistent with the following
>   sentence, how about
> 
> "For example, one peer selection algorithm is based
> only on the measurements during initial connection establishment
> between
> two peers. Since actual data transmission does not begin, the
> algorithm
> measures only the round-trip time and cannot reliably deduce actual
> throughput between the peers. A peer selection algorithm that
> simply
> uses round-trip time may result in a sub-optimal choice of peers."
> 
> 
> - Section 1.1: "network operators or third parties can collect reliable
>   network information": reliable -> "more reliable"
> 
> - Section 1.1: "topology or instantaneous bandwidth available": do you
>   want to emphasize "instantaneous"? How about ->
> 
>   "topology and bandwidth"
> 
> - Section 1.1: "Normally, such information is rather "static", i.e.,
>   information which can change over time but on a much longer time
> scale
>   than information used for congestion control on the transport layer":
> 
>  ->
> 
>"Normally, such information changes on a much longer time scale
>than i

Re: [alto] 'Link capacity' in scope?

[Jan Seedorf]

Dear Salman,

> In addition to provisioned link capacity, it is useful for end points
> to
> determine how much of their upload/download quota has been consumed
> (assuming ISPs that have a montly bandwidth cap). Like provisioned link
> capacity, this information is *indirectly* used by the peers to avoid
> peers that are running out of their quota or better select peers with
> no
> quota restriction. Such a usage is a form of application level traffic
> optimization in my opinion.

I have been following the discussion, and I think it is an important 
observation (and maybe distinction from other use cases) that your use case 
suggests **indirect** guidance in peer selection. I think the ALTO WG so far 
has considered **direct** help in peer selection, meaning that the response 
from the ALTO server is sufficient for the ALTO client to select proper peers 
without any further communication among peers. In your "P2P real-time 
communication relay" use case, the ALTO client would query information from the 
server which per se would not help it select its peers. The client rather could 
use the information obtained from an ALTO server to either a) calculate other 
information (which btw also would not be much help to the client without 
knowing information about its peer candidates) or b) advertise the obtained 
information about himself to its peers so they can select it depending on this 
information (clearly **indirect** peer selection guidance).

All of the above is merely an observation which I think might help the 
discussion.

 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Salman Abdul Baset
> Sent: Freitag, 5. Juni 2009 01:05
> To: Enrico Marocco
> Cc: alto
> Subject: Re: [alto] 'Link capacity' in scope?
> 
> On Thu, 4 Jun 2009, Enrico Marocco wrote:
> 
> >> You are probably thinking a centralized ALTO server. There is no
> reason
> >> why peers cannot act as ALTO servers which inturn obtain their
> >> link capacity information from ISP managed ALTO servers.
> >
> > Uh? I'm thinking of a protocol clients can use to query servers in
> > distributed, peer-to-peer, or centralized systems. That protocol, as
> > people on this list agreed at chartering time, will be used to carry
> > network preferences (i.e. something along the line of "from net1
> prefer
> > net2, avoid net3, select address X with priority Y...") to help peers
> in
> > peer selection optimization. Now, also considering the candidate
> > solutions that have been discussed so far (P4P/Infoexport, PROXIDOR,
> > H12...), what you are talking about sounds like a totally different
> > beast; I'm not saying that it would not be great to have that too,
> but
> > it is just not what a bunch of researchers, ISPs, P2P software
> > developers and network equipment vendors have agreed to work on.
> >
> 
> If the goal of ALTO is to only improve the performance of Bittorrent-
> like
> applications, it will be useful to clarify that.
> 
> However, it seems reasonable to consider application-level-traffic-
> optimization
> techniques for applications which may not be Bittorrent like. Real-time
> applications such as voice or video relaying or p2p conferencing are
> examples of these.
> 
> Provisioned link capacity, when used with current load, and network
> level
> feedback is useful for real-time p2p applications that need to select a
> peer for relaying or conferencing.
> 
> Determining current load on [A]DSL/cable modem seems like a problem for
> another WG. But it should not rule out passing provisioned link
> capacity
> in ALTO.
> 
> I have only asked if provisioned link capacity is in scope for ALTO. If
> not, it will be helpful to clarify which WG is more appropriate for
> determining this information.
> 
> In addition to provisioned link capacity, it is useful for end points
> to
> determine how much of their upload/download quota has been consumed
> (assuming ISPs that have a montly bandwidth cap). Like provisioned link
> capacity, this information is *indirectly* used by the peers to avoid
> peers that are running out of their quota or better select peers with
> no
> quota restriction. Such a usage is a form of application level traffic
> optimization in my opinion.
> 
> Also, like provisioned link capacity, peers do not have to explicitly
> share their remaining monthly quota but may only give an indication if
> they can support a stream or not.
> 
> -s
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] -01 version of the ALTO problem statement draft submitted

[Jan Seedorf]

Dear all,

We have just submitted a new version of the ALTO problem statement draft. We 
revised the main figure (Figure 1) which shows the interaction between 
different ALTO elements: to avoid misunderstandings, we renamed the 
"super-peer" in the figure with "resource directory", which is the proper term 
introduced in the terminology section. Of course, we also updated the 
corresponding text accordingly.

Kind regards,
Jan

========
Jan Seedorf
Research Scientist
NEC Europe Ltd., NEC Laboratories Europe, Network Division  
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-221
Fax: +49 (0)6221 4342-155
e-mail:  jan.seed...@nw.neclab.eu 

NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Adopting two I-Ds as WG documents

[Jan Seedorf]

Dear Greg,

Thanks for your comments. We discussed these among the editors of the problem 
statement draft.

We agree that the text on caching you highlight below is potentially 
misleading, and also that the phrasing of a "malicious" ISP is probably a bit 
strong. Thanks for raising these points. Accordingly, we rewrote the text on 
caching and parts of the security consideration section. You can check out the 
new text in the next version of the draft, which we will publish shortly.

Regarding content security: as Enrico has already pointed out on this list, the 
goal of ALTO is content-agnostic optimization. Thus, we did not address content 
security in the security considerations section since it is out of scope for 
ALTO (as stated in the ALTO charter).

Best regards,
 - Jan

> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> DePriest, Greg (NBC Universal)
> Sent: Mittwoch, 15. April 2009 22:52
> To: Vijay K. Gurbani; alto
> Subject: Re: [alto] Adopting two I-Ds as WG documents
> 
> In the draft problem statement is the following paragraph on caching:
> 
> "2. Content awareness:  Since caches need to store the content being
> delivered, they are subject to legal issues whenever the user does not
> have the right to access or distribute such content.  This limitation
> makes caching approaches that do not (or cannot) support digital rights
> management unusable for distributing copyrighted material.  Since, it
> is
> very difficult for an abstract file sharing proxy to know all of the
> legal parameters around distributing content, this makes caching
> unusable for many file-sharing systems.  Since this is a legal and not
> technical issue, the solution would be at the legal, not network,
> layer."
> 
> Nothing prevents a cache from receiving a black list of hashes and then
> not caching those items.  This of course avoids the acceleration of
> illicit content -- the root cause of network congestion today.
> 
> In contrast to the current draft's assertion, caching can be supportive
> of both traditional DRM (i.e., encrypted files) and legal enforcement
> activities.  It *is* a technical issue.
> 
> There is also a certain strangeness in the section on Security
> Considerations where the authors, among other things, hypothesize about
> rogue ISPs: "...in cases where the ALTO service provider maliciously
> alters results returned by queries after ALTO has gained popularity..."
> 
> 
> More important is the fact that the authors' fail to address the
> fundamental issue of content security (i.e., copyrights) that
> contributes to a situation that many find undesirable, indefensible and
> inexcusable.  Consider recent observations from Eric Schmidt (Google)
> and Sir Andrew Lloyd Webber.
> 
> Mr. Schmidt noted that the Internet is fast becoming a "cesspool."
> "Let
> me just say precisely, it's a sewer out there." [Advertising Age, April
> 7, 2009]
> 
> Sir Andrew's description to the House of Lords was similar: "The
> internet is a Somalia of unregulated theft and piracy." [Media Guardian
> April 3, 2009]
> 
> Contrary to the current draft, the issue isn't the potential for a
> wayward ISP to harm an innocent P2P application (or its unblemished
> user).  Rather, it's the need for all applications to abide by some
> agreed-upon rules of the road.  Respect for the property of others is
> one such rule we'd be wise to honor.
> 
> Doing so would begin to clean up the mess we've allowed to accumulate
> and fester.
> 
> -Original Message-
> From: alto-boun...@ietf.org [mailto:alto-boun...@ietf.org] On Behalf Of
> Vijay K. Gurbani
> Sent: Tuesday, April 07, 2009 10:04 AM
> To: alto
> Subject: [alto] Adopting two I-Ds as WG documents
> 
> Folks: To ratify the consensus during the IETF 74 meeting in
> SF, we will be adopting two documents as WG deliverables:
> 
> 1) draft-marocco-alto-problem-statement-05 will be adopted
> as the deliverable for the "problem statement" charter item.
> A new -00 WG version will be submitted by the editors shortly,
> and we will proceed to WGLC after that.
> 
> 2) draft-kiesel-alto-reqs-02 will be adopted as the deliverable
> for the "requirements document."  A new -00 WG version will
> be submitted by the editors shortly.  This draft will remain
> "alive" for a while as other issues (protocol, discovery, etc.)
> are worked on.  The editors will -- in a symbiotic relationship --
> track the emerging consensus  on these issues as well as contribute
> to these issues and update the requirements draft as consensus
> emerges.
> 
> Please post on the list if there is any objection to moving the
> above two drafts ahead.
> 
> Thanks.
> 
> - vijay (on behalf of Jon and Enrico)
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> ___

Re: [alto] About relay in realtime communication use case in alto problem statement

[Jan Seedorf]

Dear Tao,

What you say is correct: considering real-time communications, ALTO can not 
only be beneficial for peers behind middleboxes, but also in other cases. 

> whether ALTO should ignore this requirement and only consider finding
> relays
> to help traverse NAT or firewall? Can the broader relay application(not
> only
> for NAT traversal) be integrated into ALTO?
The problem statement draft gives examples for use cases to motivate the need 
for ALTO. I think for that purpose the example of NAT traversal for real-time 
communications is sufficient.

If you think your additional use case affects ALTO requirements (i.e., it 
motivates additional requirements not yet included in the requirements draft 
[draft-kiesel-alto-reqs]), this needs to be discussed, of course. Currently, I 
do not see how the example you give below asks for additional requirements for 
an ALTO client-server protocol which are not already included in 
[draft-kiesel-alto-reqs]. But please elaborate on this list if you think so and 
specifically what those requirements are.

 - Jan

> -Original Message-
> From: Tao Ma [mailto:abcdma...@gmail.com]
> Sent: Donnerstag, 2. April 2009 05:21
> To: Jan Seedorf; alto@ietf.org
> Cc: zhan...@bupt.edu.cn; lilic...@gmail.com;
> standardm...@googlegroups.com
> Subject: [alto]About relay in realtime communication use case in alto
> problem statement
> 
> Hi,
> 
> I have interests in where ALTO can be used and how. The use case of
> alto
> problem statement mentioned how ALTO would be used in realtime
> communication. It is described that the ALTO can help users which have
> limited access to Internet to find media relays with public address.
> Does
> relay only helps the users which have limited access to Internet? I
> think
> relay can help improve VoIP quality for users even fully connected to
> Internet, according to Interent anti-triangle phenomenon and AS
> relationships which is proven in by some papers and experiments. I
> doubt
> whether ALTO should ignore this requirement and only consider finding
> relays
> to help traverse NAT or firewall? Can the broader relay application(not
> only
> for NAT traversal) be integrated into ALTO?
> 
> Tao Ma
> 
> Beijing University of Post and Telecommunications, Moblie life and new
> media
> Lab
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] FW: New Version Notification for draft-marocco-alto-problem-statement-05

[Jan Seedorf]

Folks,

We just submitted a new version of the ALTO problem statement draft. Compared 
to the -04 version there are only minor changes: some text editing (based on 
comments received on the mailing list) and some new definitions regarding the 
protocols which are in scope or out of scope of the ALTO WG.

Feedback of course appreciated,

 - Jan

-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org] 
Sent: Sonntag, 8. März 2009 14:28
To: Jan Seedorf
Cc: ebur...@standardstrack.com
Subject: New Version Notification for draft-marocco-alto-problem-statement-05 


A new version of I-D, draft-marocco-alto-problem-statement-05.txt has been 
successfuly submitted by Jan Seedorf and posted to the IETF repository.

Filename:draft-marocco-alto-problem-statement
Revision:05
Title:   Application-Layer Traffic Optimization (ALTO) Problem Statement
Creation_date:   2009-03-08
WG ID:   Independent Submission
Number_of_pages: 14

Abstract:
Peer-to-peer applications, such as file sharing, real-time
communication, and live media streaming, use a significant amount of
Internet resources.  Such applications often transfer large amounts
of data in direct peer-to-peer connections.  However, they usually
have little knowledge of the underlying network topology.  As a
result, they may choose their peers based on measurements and
statistics that, in many situations, may lead to suboptimal choices.
This document describes problems related to optimizing traffic
generated by peer-to-peer applications and associated issues such
optimizations raise in the use of network-layer information.

  


The IETF Secretariat.


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] my notes from the ALTO session at IETF73

[Jan Seedorf]

 <> Dear all,

Attached are my notes from the ALTO session last week at IETF-73.

Kind regards,
Jan
ALTO Session at IETF-73
Tuesday, 13:00-15:00
Notes, Notetaker: Jan Seedorf

13:00
-- Chairs present Agenda, no objections
-- Lisa presents WG status: history of the WG (P2Pi workshop), since IETF-72: 
narrowing down of the scope of the WG, chartered as WG before IETF-73, current 
work is problem statement, requirements, and solution space; no questions from 
the audience

13:09: Aaron Falk talk about IRTF p2prg
-- p2prg has a new charter (draft form)
-- wiki is being maintained for this working group

13:12: Enrico Marocco presents the ALTO problem statement draft
-- version 3 with all comments from Dublin included
-- problem is to provide applications iwth information to perform 
better-than-random peer selection
-- presents changes from the previous version, e.g., replaced the term "oracle"
-- new terminology section
-- solution considerations include potential ALTO service providers, user 
privacy, topology hiding, coexistence with caching solutions, and protocol 
extensibility
-- no questions from the audience
-- Jon Peterson asks for comments from the audience
-- ??: potential solutions should not be part of the problem statement, what 
are the privacy consideration exactly?
-- ??: likes the document
-- ??: document includes not only problem statement but also applicability 
issues, suggests to rename the document accordingly

13:25: Sebastian Kiesel presents the requirements draft
-- terminology has been aligned with problem statement draft
-- changes since 00-version: more precise wording, removed implicit assumption 
of a "sorting oracle" solution
-- still do be done: section on overload control
-- next steps: requirements are very general, should be confined more in the 
future; definition of a "core set" of attributes for expressing preferences
-- ??: are there assumptions regarding the protocol for querying the ALTO 
service
-- Sebastian: currently not
-- ??: concerns about the process of requirements being presented a week after 
the WG has been accepted, no time to read the draft
-- Jon Peterson:`how many people have read the document? Answer: many people in 
the room
-- Hannes Tschofenig: requirements docs are a waste of time, delays everything 
but does not produce anything
-- Ted Hardie: the document needs some work, many things are implicit but not 
explicitly mentioned, suggests to state requirements more explicit
-- Dave Crocker: seems to be a tough topic, people need to be in sync, 
suggestion: step back, the problem needs to be understood better before 
continuing with requirements
-- ??: too early for a requirements to be authorative
-- Hannes Tschofenig: requirements docs are not of much help, what are the 
really challenging questions?, this should be in the doc
-- ??: dislikes requirements docs, understant what the problem really is first
-- Jon Peterson: requirements are in the charter
-- Vijay Gurbani: problem statement needs to be understood more and discussed 
on the list to establish a common ground
-- Vijay Gurbani: authors of the requirements draft should talk to the people 
actually deploying solutions
-- Daryl Malas: likes requirements docs, they help to frame the path of the WG
-- Stanislav Shalunov: it is ok to dive into solutions and then to revisit the 
requirements

13:47: Richard Yang presents "P4P Design and Implementation"
-- two kinds of P4P portal services: location portal service and pDistance 
portal service
-- location portal service allows an ISP to aggregate the internet address 
space; uses PID to denote a set of network locations
-- question from audience (by ??): does each ISP run its own location portal 
service? Answer: Yes
-- Anja Feldmann: who would use such a service? Answer: so far envisioned to be 
used by client 
-- pDistance portal service allows an ISP to define the pDistance for any given 
pair of network locations
-- there can be different types of pDistance (e.g., ordinal, numerical)
-- Ted Hardie: suggests to use existing mechanisms for a "looking glass" on the 
Internet

14:00: Richard Woundy presents Comcast's Experiences In a P4P Technical Trial 
(draft-livingood-woundy-p4p-experiences-02)
-- first P4P trial over cable infrastructure
-- results: P4P improved download speeds, was effective in reducing 
inter-domain traffic, Comcast believes P4P has merit and will continue working 
on this
-- next steps are more trials
-- ??: does the PNA schema use P4P technology? Answer: No, but it is comparable

14:15: ?? presents on "ALTO Information Export Service" 
(draft-shalunov-alto-infoexport-00)
-- protocol overview: ISP prepares ALTO information, application díscovers the 
service URL and uses http to fetch ALTO information from service (discovery 
mechanism out of scope)
-- format is: type designator (asn or cidr), AS number or IP prefix, priority 
value
-- key concept is