Subject: [Idnet] Architecture and standard opportunities of IDN

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Jul 2017 11:38:09 +0000

Hi, all,

Please find the below figure that I shared in the IDN discussion meeting last week in Prague. This illustrates the IDN architecture in a very generic way. The on-site participants had the very similar understanding that the upper left box - the unified and selected data is should be the prior work towards standardization. Also, the participants shared the same opinion that the data structure may be various among use cases. So, we should keep discussing on use cases with the target to converge on one or two significant and specific use cases.

Regards,

Sheng

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 27 Jul 2017 09:45:12 +0900

Dear Sheng,

First of all, and considering my recent experience with the Network
Slicing work, I think we have some aspects of our work that are probably
essential for the IETF and network technology in general:

- As you mention and all of us know well, we need to standardize the
  data format, so it is a good opportunity to define some ontology and
  the corresponding YANG model that structures such data.

- We have also a good opportunity to define a "benchmarking framework"
  that can be used with whatever dataset we can gather in the future in
  order to validate some approach. This would be a combination of YANG
  model and work protocols (not network, but procedure protocols) that
  would be required to ensure the results are universally valid and can
  be contrasted to other results. This is essential in any discipline,
  as we can find in areas such as multimedia communications or computer
  vision, but the networking area does not have anything like it.

- The definition of "wire protocols", interfaces, and the format of data
  exchanged (also as YANG models) that are easily identified in the IDN
  architecture figure that I think all of us support to some extent.

- Of course, the IDN reference architecture (but this has been deeply
  discussed).

As you can perceive, I am trying to be practical. This somehow contrasts
with my typical views, which are normally quite abstract, but those work
are quite obvious, are not defined elsewhere, and can be a good starting
point to form a WG in the future. For the moment, we can address such
work through other RG/WG (e.g. NMRG) so we can begin the writing of some
drafts-of-drafts for IETF 100. If you are interested on doing it, please
let me know and we can define some schedule and some rough ToC for those
documents. Thank you very much.

Regards,
Pedro

> _______________________________________________
> IDNET mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idnet

-- 
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: Jérôme François <[email-masked]>
Date: Fri, 28 Jul 2017 12:13:16 +0200

Hi,

>   the corresponding YANG model that structures such data.
Do you imagine kind of a transformation process in the architecture as
data to be used can come with pre-existing various data formats ?
>   vision, but the networking area does not have anything like it.
Fully agree, this is essential for comparing results. This is well
linked to datasets issues as well and in general with reproducible
experiments.

---

From: 김민석 <[email-masked]>
Date: Mon, 31 Jul 2017 02:06:12 +0000

Dear Sheng,

Thank  you for giving us last IDNET side-meeting in Prague.

Many guys mentioned data-set problems in the IDN archetecture, so I strongly agree with these kinds of opinions.

BUT, we should carefully consider a ML-based algorithm set-up for Reinforcement Learning (RL) that you described in the other slide. Reward is one of the components in RL algorithm so that we should take all of the options of RL into consideration, such as which action we can take in the loop, which state should be optimized for reward, how policy will cover and dominate for learning process.

I submitted and presented our related internet draft based on RL in NMRG, Prague so that it might help to figure out more specifically. Hopefully. we are additionally able to discuss related RL setting-up more by email discussion or next meeting.

Best,

Min-Suk Kim

Senior Researcher / Ph.D.

________________________________
보낸 사람 : "Sheng Jiang" <[email-masked]>
보낸 날짜 : 2017-07-26 20:38:50 ( +0900 )
받는 사람 : [email-masked] <[email-masked]>
참조 : yanshen <[email-masked]>
제목 : [Idnet] Architecture and standard opportunities of IDN

Hi, all,

Please find the below figure that I shared in the IDN discussion meeting last week in Prague. This illustrates the IDN architecture in a very generic way. The on-site participants had the very similar understanding that the upper left box – the unified and selected data is should be the prior work towards standardization. Also, the participants shared the same opinion that the data structure may be various among use cases. So, we should keep discussing on use cases with the target to converge on one or two significant and specific use cases.

Regards,

Sheng

---

From: yanshen <[email-masked]>
Date: Mon, 31 Jul 2017 12:25:04 +0000

Hi Jerome,

> -----Original Message-----
> From: IDNET [mailto:[email-masked]] On Behalf Of Jér?me Fran?ois
> Sent: Friday, July 28, 2017 6:13 PM
> To: [email-masked]
> Subject: Re: [Idnet] Architecture and standard opportunities of IDN
> 
> Hi,
> 
> > Slicing work, I think we have some aspects of our work that are
> > probably essential for the IETF and network technology in general:
> >
> Do you imagine kind of a transformation process in the architecture as data to be
> used can come with pre-existing various data formats ?

My two cents. I ever think about that. The proposed data format should be easily "re-constructed" via existing data formats. The new attributes in the new format should can be auto-filled. Like the transformation of "XML schema" to "YANG".

> Fully agree, this is essential for comparing results. This is well linked to datasets
> issues as well and in general with reproducible experiments.
> > As you can perceive, I am trying to be practical. This somehow
> > contrasts with my typical views, which are normally quite abstract,
> > but those work are quite obvious, are not defined elsewhere, and can
> > be a good starting point to form a WG in the future. For the moment,
> > we can address such work through other RG/WG (e.g. NMRG) so we can
> > begin the writing of some drafts-of-drafts for IETF 100. If you are
> > interested on doing it, please let me know and we can define some
> > schedule and some rough ToC for those documents. Thank you very much.
> >
> > Regards,
> > Pedro
> >
> >> Please find the below figure that I shared in the IDN discussion meeting last
> week in Prague. This illustrates the IDN architecture in a very generic way. The
> on-site participants had the very similar understanding that the upper left box -
> the unified and selected data is should be the prior work towards standardization.
> Also, the participants shared the same opinion that the data structure may be
> various among use cases. So, we should keep discussing on use cases with the
> target to converge on one or two significant and specific use cases.
> >>
> >> Regards,
> >>
> >> Sheng
> >
> >

---

From: yanshen <[email-masked]>
Date: Mon, 31 Jul 2017 13:15:24 +0000

Dear Kim,

May you have seen that we have a consensus on the potential standardization point of data and data format.

In your experience, what the structure or feature that ML-based algorithm potentially tend to? If we have a consensus and full view in this question, the data structure may be clear.

For example, if we want to train a model with QoS data (or reward). Assume that these data can be captured via some method. Some following key characters of data structure may be needed:

-          QoS data, such as delay. It may be organized with time series/quantized (the “reward”) / ...

-          Starting-ending time. It is significant and should be differentiated.

-          Time interval. We can capture the delay values in different frequency. High frequency time series delay value may be “down-sampled” when it is used in training low frequency model.

-          Source-destination. Obviously.

-          TBD

Any other keys?

Yansen

From: 김민석 [mailto:[email-masked]]
Sent: Monday, July 31, 2017 10:06 AM
To: Sheng Jiang <[email-masked]>; [email-masked]
Cc: yanshen <[email-masked]>
Subject: RE: Architecture and standard opportunities of IDN

Dear Sheng,

Best,

Min-Suk Kim

________________________________
보낸 사람 : "Sheng Jiang" <[email-masked]<mailto:[email-masked]>>
보낸 날짜 : 2017-07-26 20:38:50 ( +0900 )
받는 사람 : [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
참조 : yanshen <[email-masked]<mailto:[email-masked]>>
제목 : [Idnet] Architecture and standard opportunities of IDN

Hi, all,

Regards,

Sheng