On 7/3/12 1:50 AM, Haiyong Xie wrote:
Hi Richard,
Thanks very much for your comments. Please see my inline responses below.
On 07/01/2012 08:41 PM, Y. Richard Yang wrote:
Hi Haiyong, Tina, Hongtao, and Diego,
A good document! Here are some quick feedback:
- One take-away message that the document appears trying to convey is
Vertical (V) vs Horizontal (H) architectures. My understanding of your
definition
is that V is a one-to-many setting, i.e., one ALTO Server to m SDN
Controllers (SC),
while H is one-to-one, i.e., one ALTO Server to one SC.
The H architecture implies that the network should NOT be segmented,
i.e., there exists only one SC; otherwise, the network will have
multiple ALTO servers, each is working with corresponding SC only, but
without exchanging information among multiple ALTO servers (we do not
have a protocol to do so yet).
This is different from my understanding. I thought that H still could allow
network partition, say m sub-networks. Then there are m SCs and m ALTO
servers. The m SCs can form a mesh/peering to work together. Now I
understand
your design. But how about the partitioned H design? Is it allowed? If
there are
convincing use cases for inter-ALTO Server in your design, then it
identifies a need for inter-ALTO. What do you think?
Why is the information flow
in H only SC <- ALTO S (Sec. 3.2), not the other way around? In an SDN
setting, I
agree that an SC should already collect fine-grained, dynamic
information for its
controlled domain. ALTO currently does not define how its information is
collected/provisioned, but SC provides a good source (Sec. 4.3.2) of
information
for ALTO Server to aggregate and conduct abstraction. I see good value
in this
direction of information flow. I feel that this is mostly a common
problem across H
and V. Hence I would not discard the H architecture right away.
Adding SC->ALTO S in the H architecture does not add much new value.
Since the ALTO Server is working for the specific SDN domain only, the
more important of problem, i.e., how to coordinate multiple SCs in the
whole network, remains unsolved. Plus, in the H architecture, we really
do not have to differentiate ALTO S from SC, as the former could be
easily integrated into the latter (since SC has the most updated network
information already).
From a modular design's point view, an SC could be a multiple-functional
components, multiple-machines system (e.g., front end, policy server,
database server). Hence, although conceptually we could say that an ALTO
Server can be integrated into an SC, a more detailed may reveal more
structures.
I agree that generally speaking, adding the SC->ALTO S information flow
is pretty helpful to ALTO, as this enables ALTO to collect network
information, which has not been addressed previously yet. However, we
believe that the main distinctions between the V and H architectures
include not only whether we have the SC->ALTO S flow, but also how we
should decompose the ALTO related functionalities and design an
efficient, evolvable architecture to support the growth of both SDN and
ALTO.
A concern is
whether we are ready to define the SC -> ALTO Server information flow,
given the "early-stageness" of SDN. A related general comment is that
it maybe quite
helpful to extract common problems (e.g., unknown/dynamic network cost as
you mentioned) and new possibilities for ALTO when introducing SDN,
instead of
a specific setting of a network being partitioned into many
sub-networks in a V
architecture. What do you think?
Partitioning the network and defining common problems/possibilities of
SC->ALTO S information flow are two orthogonal problems. We believe that
both are equally important. However, the first problem (partitioning the
network) will largely determine what the SDN+ALTO architecture looks
like, while the second problem is more about the types of detailed
network information, its format, etc. From this perspective, it seems
that the first problem is more important -- if the architecture is not
set right at the beginning, to fix it at some later time would be
difficult and costly. This draft is mainly focusing on the first
problem, we may need another draft dedicated to the second problem.
Defining the first problem--partitioning the network clearly provides a
good use case and problem problem definition. This is a quite interesting
perspective.
A curious question, does the ALTO servers
(as well as the SC) in H form some kind of mesh (peering) among
themselves?
Given current status of ALTO, we assumed that there is no peering among
ALTO servers. However, if ALTO server peering becomes available and
adopted, then the H architecture (and the SC->ALTO S flow) would make
much more sense, which allows us to compare the two architectures more
thoroughly.
- The document seems to imply some kind of exclusive SC/net app
setting: either
SC or net app, but not both. Do I misunderstand it? This depends on
how one
define the scope of SC. There can still be net apps running. Does it
make sense to
include (explicitly) the net apps into your discussions/figures to
include 4 types
of entities: devices, SC, ALTO Server, and net apps?
Actually we did not mean to imply any kind of exclusive SC/net app
setting. We need to update the draft to make it more explicit. In the
figures, we did not include the net apps for the sake of simplicity.
When we update the draft, we will add them to the figures.
sounds good.
I like your distinction between
SDN-aware and SDN-unaware apps. I am not sure I fully agree or
understand your
statement that SDN-aware apps would prefer direct communications with
SC, but
this will be an important architecture discussion at the ALTO meeting.
What we have in mind is that since some apps are SDN aware, then it may
prefer to behave differently from SDN unware apps (which does not
directly communicate with SC), i.e., directly communicate with SC, which
allows more flexibility and new possibilities of leveraging the SDN
capabilities. Apparently discussions would be very helpful, and I am
sure it would be a very interesting discussion about SDN-awareness and
-unawareness at the ALTO meeting.
Thanks.
Richard
On 6/29/12 6:15 AM, Haiyong Xie wrote:
Hi All,
This is a proposal on the interaction between ALTO and SDN we'd like
to discuss at our next meeting in Vancouver. This draft replaces the
older submission draft-xie-alto-sdn-use-cases-01.txt which was
withdrawn already.
Comments or discussions are extremely welcome and appreciated.
Best regards,
Haiyong
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 28, 2012 3:07 PM
To: Haiyong Xie
Cc: [email protected]; Hongtao Yin; Tina TSOU
Subject: New Version Notification for
draft-xie-alto-sdn-extension-use-cases-00.txt
A new version of I-D, draft-xie-alto-sdn-extension-use-cases-00.txt
has been successfully submitted by Haiyong Xie and posted to the
IETF repository.
Filename: draft-xie-alto-sdn-extension-use-cases
Revision: 00
Title: Use Cases for ALTO with Software Defined Networks
Creation date: 2012-06-28
WG ID: Individual Submission
Number of pages: 28
URL:
http://www.ietf.org/internet-drafts/draft-xie-alto-sdn-extension-use-cases-00.txt
Status:
http://datatracker.ietf.org/doc/draft-xie-alto-sdn-extension-use-cases
Htmlized:
http://tools.ietf.org/html/draft-xie-alto-sdn-extension-use-cases-00
Abstract:
The introduction of SDN fundamentally changes the way that the ALTO
works. This draft describes the Vertical Architecture and the
Horizontal Architecture allowing coherent coexistence of application
layer traffic optimization (ALTO) with software defined network
(SDN). Unique requirements for design and operations are identified
and summarized, suggesting that the Vertical Architecture allows
better division, management, flexibility, privacy control and long-
term evolution of the network. We also define the main interactions
and information flows, and present a set of use cases to illustrate
how we extend ALTO to support SDN, in the Vertical Architecture.
The IETF Secretariat
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
