Hi Jensen,

Thank you for your response.

see comments inline.

On 11.08.2016 19:16, Jensen Zhang wrote:
Hi Hans,

Is it possible to compress the cost map by using routing state abstraction? I think it is a potential solution.
As far as I understand the routing state abstraction draft, it can be used to eliminate links e.g. from path-vectors regarding client defined conditions to reduce the size of the cost-map. However, I see two potential limitations of routing state abstraction in full cost maps.

1. Assuming a full mesh cost map where costs from every PID to every PID are provided, so we have a flow from every PID to every PID. The more flows, the more fine grained is the routing state abstraction, since the number of shared links among different flows increases. If no information should be lost, I think the number of links that could be eliminated decreases with the number of flows. So, having many flows will result in little to no size reduction. Please correct me, if I got this wrong. 2. The computation effort for a large number of PIDs in large networks might exceed an acceptable limit.

Another solution may be to add a proxy layer to compress and decompress ALTO protocol messages. It will reduce the communication time and not change the implementation of ALTO servers and clients. But compression and decompression will increase extra processing time.

Yes, compression is a way to reduce the size at the cost of extra processing. It reduces the map size to 3.7MB without and 11MB with path-vector but keeps the size ratio at 1:3.

Hans


We haven't test such large-scale networks, but it is indeed a problem which need to be handled.

Best,
Jensen

On Thu, Aug 11, 2016 at 9:08 PM, Hans Seidel <[email protected] <mailto:[email protected]>> wrote:

    Hi Richard, all,

    after the ALTO session in Berlin, we shortly talked with Ingmar
    about the impact of path-vector on the size of cost maps
    especially in large-scale networks.

    I carried out some tests with path-vector cost maps based on our
    data. Our cost maps are already very large but path-vector maps
    are about three times larger (~50 MB vs. ~150 MB in uncompressed
    state). In average we have round about 4 hops between two PIDs
    which leads to an average path-vector of the same length. ECMP was
    not considered in the test but it will certainly further increase
    the size of the map.

    Our idea to reduce cost map size is to provide topology
    information, e.g. with the property map presented in the
    unified-props draft, and let the client carry out the path
    determination. This means, the ALTO server provides the network,
    cost and property map to enable clients to get their desired level
    of detail for the path costs.

    I also think this approach can coexist with path-vector cost maps.
    An ALTO server can provide both cost maps with and without path
    vector and a property map providing the topology. This way it is
    up to the client whether it wants to save bandwidth and invests
    some processing time to perform path determination by itself or it
    fetches the full path-vector cost map.

    Any thoughts on this?

    Cheers
    Hans


    On 01.08.2016 23:37, Vijay K. Gurbani wrote:

        Folks: As the (draft) minutes [1] of IETF 96 reflect, there
        was general
        consensus on adoption of path vector and routing state abstraction
        documents towards the charter deliverable of graph representation
        formats in ALTO.

        The chairs will like to start a call for adoption of the two
        documents
        --- https://tools.ietf.org/html/draft-yang-alto-path-vector-03
        <https://tools.ietf.org/html/draft-yang-alto-path-vector-03> and
        https://tools.ietf.org/html/draft-gao-alto-routing-state-abstraction-03
        
<https://tools.ietf.org/html/draft-gao-alto-routing-state-abstraction-03>
        --- as deliverables towards the charter item.

        Note that there remains some ambiguity (in the chair's mind)
        on whether,
        once adopted, these will proceed as two drafts or whether they
        will be
        merged in one.  The authors of these drafts are urged to provide
        clarity on the evolution of these documents.

        The call for adoption runs for two weeks, from Mon Aug 1, 2016
        to Mon
        Aug 15, 2016.  This will be a good time to comment on the list and
        inform the working group of any issues with adopting these
        items, or
        whether the working group was remiss in considering other
        documents.
        Please post to the list.  (Even a simple "I support these
        documents
        towards charter deliverable" is a good indication.)

        Thanks,

        [1]
        https://www.ietf.org/proceedings/96/minutes/minutes-96-alto
        <https://www.ietf.org/proceedings/96/minutes/minutes-96-alto>

        - vijay


    _______________________________________________
    alto mailing list
    [email protected] <mailto:[email protected]>
    https://www.ietf.org/mailman/listinfo/alto
    <https://www.ietf.org/mailman/listinfo/alto>




_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to