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

["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). 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