Re: [rrg] Questions about Enhanced Efficiency of Mapping Distribution Protocols

[Charrie Sun <[e-mail]>]

2009/12/30 Sriram, Kotikalapudi <[e-mail]>

> Sun:
>
> Thanks for the comments/questions.
> With your permission, I am posting them and my responses to the RRG list.
> Please see my responses inline below. I hope they are helpful.
>
> Sriram
>
> >From: Charrie Sun [[e-mail]]
> >Sent: Wednesday, December 23, 2009 11:27 PM
> >To: Sriram, Kotikalapudi
> >Subject: Questions about Enhanced Efficiency of Mapping Distribution
> Protocols
> >
> >Hi Sriram,
> > I have recently read your proposal of "Enhanced Efficiency of
> >Mapping Distribution Protocols in Map-and-Encap Schemes"
> >for the scalable routing task. I raised some questions and want to
> >discuss with you. Since it includes some pictures in the
> >discussion I put them in the attachment.
> >
> >
> >1)     The figure below which you showed in your presentation slide
>
> KS: For the benefit of people in this list, this is the figure in slide 20
> of my presentation:
> http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf
>
> >Well why does the slope of Approach 2’s curve become flatter?
> >As each time a response sends only one relevant mapping
> >I thought the first-packet-delay wouldn’t change in the theoretical sense.
> >What matters more, I think, would be the average delay of all
> first-packet.
> >Say, comparing as to a common prefix, and this would compare
> >the first two approaches more explicitly.
>
> KS: This is a heuristic plot. Yes, I had the _average_ of first packet
> delay in mind.
> When the # of exceptions (x-axis) is quite small, in approach 2 the first
> packet may
> benefit from a cache at ILM-R (see slide 14), and when the # of exceptions
> goes higher,
> then most map requests will propagate to ILM resulting in higher delays.
> But you are right
> that the plot will be primarily flat then onwards. In approach 1, on the
> other hand, when
> the # of exceptions is higher, then the cache hit ratio will be perfect for
> “first” packets of
> subsequent sessions because the “first” packet of the very first session
> destined for
> that prefix has already fetched all of the maps (including all exceptions).
> But the first
> packet of the very first session destined for a prefix in consideration has
> to wait for
> many exception maps to be processed at the ILM-R and the ITR. Hence, the
> more
> rapidly increasing delay-plot for approach 1. I think you were OK with the
> plot for
> approach 1, but I thought I will try to elaborate on explanation for both
> delay-plots
> and try to put it all in perspective. Thanks for the question.
>
> >2)     The second question arises when you talk about hierarchy of ETRs in
> Slide 23.
>
> KS: Here you are referring to slide 23 / slide 24 in the presentation:
> http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf
> -- also same as Figure 3 (page 6) in the detailed document:
> http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf
>
> >Well I think it is in fact a matter of core’s routing system, and each ETR
> should
> >advertise their directly-mapped EID prefixes. Though higher level ETRs can
> >aggregate mapping to alleviate the load of mapping distribution, this can
> >mix up mapping system with the routing system. However how to define
> >“core” and “edge” is still a hard problem :)
>
> KS: Your comment here is well taken. Yes, in general “ETR should advertise
> their directly-mapped EID prefixes” as you have stated. My thinking is that
> if lower-level ETRs (see Slides 23 and 24) DO indeed delegate to a
> higher-level
> ETR the aggregation and notification of mapping messages, then the
> higher-level
> ETR can suppress the fragments (deaggregates) while it announces a map for
> the covering aggregate EID. However, if a subnet is multi-homed to multiple
> ETRs
> (see slide 24 or Fig. 3 in the detailed document), then the subnet
> (deaggregate)
> gets announced by another higher-level ETR even thought the parent
> higher-level
> ETR has announced only the aggregate. In this situation, our proposal is to
> depref
> the deaggregated EID subprefix in the mapping distribution protocol by
> incorporating
> a “backup” indicator (see slide 24).


Then this backup information can make the same storage and distribution cost
as to the original non-aggregated mappings, right?

> A sending host will normally receive
> a response (to a map request) with information about the primary ETR
> (i.e., the aggregating ETR) as the locator for a prefix. The backup ETR
> will be used in a map response only in circumstances when primary ETR
> is known to be in a failure-recovery state or has otherwise withdrawn the
> aggregate.
> Finally, on your last point, yes, I am also somewhat troubled about
> definition of "core" and "edge" separation.
>
> Sriram