Why measurements using api are apt to fail while those using web interface can usually succeed?
Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong
Hi Sun, If you could provide us a few of the measurement IDs for the ones that worked via the UI, along with a few IDs from the API created ones, we would be happy to take a look and see if we can determine the cause. You can include them here on the mailing list or send them to my email directly. Kind Regards, Stephen Atlas UI
On Dec 19, 2024, at 4:22 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote:
Dear all,
I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied."
Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12.
Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful.
Below is the Python code I used to launch the measurements:
from ripe.atlas.cousteau import (
Traceroute,
AtlasSource,
AtlasRequest,
AtlasCreateRequest,
AtlasResultsRequest,
AtlasLatestRequest,
ProbeRequest
)
traceroute = Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {} {}".format(dstip, probe_type, probe_value), protocol='ICMP')
if probe_type == 'asn': probe_value = int(probe_value)
source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]})
_key = ATLAS_API_KEY_2
for _ in range(2):
atlas_request = AtlasCreateRequest(
start_time=datetime.utcnow() + timedelta(random.randint(0, 1)),
key=_key,
measurements=[traceroute],
sources=[source],
is_oneoff=True
)
(is_success, response) = atlas_request.create()
if is_success:
print('create_task', dstip, is_success, response)
msm_id = response['measurements'][0]
return
Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance.
Thank you very much!
Best regards, Sun Letong
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Thank you very much for your attention. I collect some measurements below: description |msm-id via UI|msm-id via API ________________________________________________________________________________________________________ select a probe from AS55699 and traceroute to 117.54.52.6 | 84972798 | 84952226 select a probe from AS141082 and traceroute to 117.54.52.6| 84972804| 84952169 select a probe from AS45305 and traceroute to 117.54.52.6 | 84972821| 84952193 select a probe from AS142360 and traceroute to 117.54.52.6| 84972826| 84952233 select a probe from AS18106 and traceroute to 117.54.52.6 | 84972892| 84952216 select a probe from AS24213 and traceroute to 117.54.52.6 | 84972907| 84952182 select a probe from AS140423 and traceroute to 117.54.52.6| 84972912| 84952198 select a probe from AS142348 and traceroute to 117.54.52.6| 84972917| 84952221 -----Original Messages----- From:"Stephen Suess" <ssuess@ripe.net> Send time:Thursday, 12/19/2024 15:14:51 To: 孙乐童 <slt20@mails.tsinghua.edu.cn> Cc: ripe-atlas@ripe.net Subject: Re: [atlas] Why measurements using api are apt to fail while those using web interface can usually succeed? Hi Sun, If you could provide us a few of the measurement IDs for the ones that worked via the UI, along with a few IDs from the API created ones, we would be happy to take a look and see if we can determine the cause. You can include them here on the mailing list or send them to my email directly. Kind Regards, Stephen Atlas UI On Dec 19, 2024, at 4:22 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote: Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi again Sun, The most obvious difference is that the UI measurements are using UDP (vs your api specified ICMP), so I believe this is what causes the difference. Try some of your API spec'd msms over UDP (if you are able) and I assume they will be successful as they are in the UI. Hope this helps. Kind regards, Stephen Atlas UI
On Dec 19, 2024, at 8:46 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote:
Thank you very much for your attention. I collect some measurements below:
description | msm-id via UI | msm-id via API
________________________________________________________________________________________________________
select a probe from AS55699 and traceroute to 117.54.52.6 | 84972798 | 84952226 select a probe from AS141082 and traceroute to 117.54.52.6| 84972804 | 84952169 select a probe from AS45305 and traceroute to 117.54.52.6 | 84972821 | 84952193 select a probe from AS142360 and traceroute to 117.54.52.6| 84972826 | 84952233 select a probe from AS18106 and traceroute to 117.54.52.6 | 84972892 | 84952216 select a probe from AS24213 and traceroute to 117.54.52.6 | 84972907 | 84952182 select a probe from AS140423 and traceroute to 117.54.52.6| 84972912 | 84952198 select a probe from AS142348 and traceroute to 117.54.52.6| 84972917 | 84952221
-----Original Messages----- From: "Stephen Suess" <ssuess@ripe.net <mailto:ssuess@ripe.net>> Send time: Thursday, 12/19/2024 15:14:51 To: 孙乐童 <slt20@mails.tsinghua.edu.cn> Cc: ripe-atlas@ripe.net Subject: Re: [atlas] Why measurements using api are apt to fail while those using web interface can usually succeed?
Hi Sun,
If you could provide us a few of the measurement IDs for the ones that worked via the UI, along with a few IDs from the API created ones, we would be happy to take a look and see if we can determine the cause. You can include them here on the mailing list or send them to my email directly.
Kind Regards,
Stephen Atlas UI
On Dec 19, 2024, at 4:22 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote:
Dear all,
I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied."
Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12.
Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful.
Below is the Python code I used to launch the measurements:
from ripe.atlas.cousteau import ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest )
traceroute = Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {} {}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type == 'asn': probe_value = int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]})
_key = ATLAS_API_KEY_2 for _ in range(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True
) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return
Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance.
Thank you very much!
Best regards, Sun Letong
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Stephen, Thank you so much for your insightful advice. After specifying UDP in my API, the success rate has noticeably improved, with 7 out of 12 measurements returning the expected results. As there are still failed measurements, I repeated the test several times with a 10-second interval between two measurements, while each time there are 5 to 6 random measurements failed, showing the "specified" status. I then attempted to re-issue a measurement whenever the original one failed, and it seems that no more than three attempts are needed to obtain a successful measurement for a designated source and destination. Although the issue appears to be resolved, I am still curious about the origin of the "specified" status. According to the Atlas documentation, "specified" refers to a state in which "the measurement has been defined and sent to the infrastructure to be relayed to the probes." However, based on my experiment, once a measurement enters the "specified" state, it stays there for an extended period and eventually transitions to "scheduling denied." Thanks again for your precious help! Best regard, Sun -----Original Messages----- From:"Stephen Suess" <ssuess@ripe.net> Send time:Thursday, 12/19/2024 18:48:27 To: 孙乐童 <slt20@mails.tsinghua.edu.cn> Cc: ripe-atlas@ripe.net Subject: [atlas] Re: Why measurements using api are apt to fail while those using web interface can usually succeed? Hi again Sun, The most obvious difference is that the UI measurements are using UDP (vs your api specified ICMP), so I believe this is what causes the difference. Try some of your API spec'd msms over UDP (if you are able) and I assume they will be successful as they are in the UI. Hope this helps. Kind regards, Stephen Atlas UI On Dec 19, 2024, at 8:46 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote: Thank you very much for your attention. I collect some measurements below: description |msm-id via UI|msm-id via API ________________________________________________________________________________________________________ select a probe from AS55699 and traceroute to 117.54.52.6 | 84972798 | 84952226 select a probe from AS141082 and traceroute to 117.54.52.6| 84972804| 84952169 select a probe from AS45305 and traceroute to 117.54.52.6 | 84972821| 84952193 select a probe from AS142360 and traceroute to 117.54.52.6| 84972826| 84952233 select a probe from AS18106 and traceroute to 117.54.52.6 | 84972892| 84952216 select a probe from AS24213 and traceroute to 117.54.52.6 | 84972907| 84952182 select a probe from AS140423 and traceroute to 117.54.52.6| 84972912| 84952198 select a probe from AS142348 and traceroute to 117.54.52.6| 84972917| 84952221 -----Original Messages----- From: "Stephen Suess" <ssuess@ripe.net> Send time: Thursday, 12/19/2024 15:14:51 To: 孙乐童 <slt20@mails.tsinghua.edu.cn> Cc: ripe-atlas@ripe.net Subject: Re: [atlas] Why measurements using api are apt to fail while those using web interface can usually succeed? Hi Sun, If you could provide us a few of the measurement IDs for the ones that worked via the UI, along with a few IDs from the API created ones, we would be happy to take a look and see if we can determine the cause. You can include them here on the mailing list or send them to my email directly. Kind Regards, Stephen Atlas UI On Dec 19, 2024, at 4:22 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote: Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Sun, I've looked at the measurements when you sent your mail and at least at that time the measurements you've scheduled via the API were set to start in the future. In that case they show up in the UI as "Specified" until the scheduled start time. Not sure if that was intentional, but maybe cousteau handles timestamps differently than you think (e.g., assumes UTC instead of local time)? Just a guess. Best, Malte
Hi Malte: Yes, it was the time designation that caused the confusion! In my code, I initially wrote: atlas_request=AtlasCreateRequest( start_time=datetime.utcnow(), However, when I stepped through the debugging process, I encountered an error indicating that the measurement start time must be in the future. To resolve this, I added a random delay to the start time: start_time=datetime.utcnow() +timedelta(random.randint(0, 1)), I assumed that the unit of the timedelta parameter was seconds, but it turns out it is actually in days. Apologies for the mistake and the bothering I made. Thank you all for your kind help! Best regards, Sun -----Original Messages----- From:"Malte Tashiro via ripe-atlas" <ripe-atlas@ripe.net> Send time:Friday, 12/20/2024 10:51:57 To: 孙乐童 <slt20@mails.tsinghua.edu.cn> Cc: ripe-atlas@ripe.net Subject: [atlas] Re: Why measurements using api are apt to fail while those using web interface can usually succeed? Hi Sun, I've looked at the measurements when you sent your mail and at least at that time the measurements you've scheduled via the API were set to start in the future. In that case they show up in the UI as "Specified" until the scheduled start time. Not sure if that was intentional, but maybe cousteau handles timestamps differently than you think (e.g., assumes UTC instead of local time)? Just a guess. Best, Malte ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Sun, I've looked at the measurements when you sent your mail and at least at that time the measurements you've scheduled via the API were set to start in the future. In that case they show up in the UI as "Specified" until the scheduled start time. Not sure if that was intentional, but maybe cousteau handles timestamps differently than you think (e.g., assumes UTC instead of local time)? Just a guess. Best, Malte ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (4)
-
Malte Tashiro -
stephane＠mouton.com -
Stephen Suess -
孙乐童