Subject: Re: [IMRG] Requirements for IMP

From: Maurizio Molina <[email-masked]>
Date: Thu, 04 Dec 2003 18:07:44 +0100

Jon, please see some comments inline on some of your points.
When specific protocol aspects are discussed, I refer to
http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt
Maurizio

jon bennett wrote:

>
> A number of times in this discussion a question has been raised as to
> whether or not a certain facility was required in IMP. I think it
> would be useful to start exploring what the requirements should be as
> that will enable us see which bits of functionality there is agreement
> on and which bits there is disagreement on. It will also hopefully
> identify those areas where that have not been addressed at all as of yet.
>
> I have listed the topics below so that people who might only be
> interested in one or two of them can skip to the ones they care about
> without reading the whole message. My hope is for as many people as
> possible to comment on these since we can't improve the protocol
> without feedback.
>
> The list of items below is not intended to be complete, rather it is a
> starting point as well as a list of items for which some answers lead
> to perhaps non-obvious implications, some are items which are simply
> contentious and some items which have been assumed to be required but
> perhaps should not be required.
>
> 1) Measurement of the Reverse Path
> 2) Length of Measurable Path
> 3) Host Processing, Raw Sockets or Ports
> 4) IP Address in Path Record
> 5) Timestamp in Path Record
> 6) TTL in the path record
> 7) Information Request
> 8) Information Request part of IMP or a UDP Based Service
> 9) Redirection
>
>
> ----------------------------------------------------------------
>
> 1) Measurement of the Reverse Path
>
> Is it a requirement of IMP to measure the reverse path? Well 1/2 the
> time the problem will be in the reverse path so this seems like an
> obvious "Yes".
>
> An implication of this is that it (on average) doubles the number of
> records that need to fit in the packet.
>
> Is it a requirement of IMP to measure a broken reverse path? Well when
> paths break 1/2 the time it will be in the reverse path so this would
> also seem to be a "Yes".
>
> This has a rather more significant implication, if the reverse path is
> broken how do you get the IMP packet back to see where the break is? 

Isn't there the same problem if the break is in the "forward" path?

>
>
>
> 2) Length of Measurable Path
>
> Is it a requirement of IMP to be able to measure paths of any length?
> If the path works (as opposed to loops) then we would want to measure
> all of it regardless of length so the answer would seem to be "Yes".
>
> An implication of this is that for small packet sizes and/or reverse
> path measurements some method of preventing the first N hops from
> always filling the packet is needed, otherwise only the first N hops
> will ever be measurable. 

I think this feature is needed. More in general, I think that what is 
needed is the ability of selectively enabling/disabling IPMP routers to 
insert path records.
The main two reasons I see for it to be useful are the following.

1) It would provide a way to directly test whether it's true or not that 
the full processing of IPMP packets is done as if corresponding ordinary 
packets were processed (requirement of 
 http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt, sec. 4.4).
Suppose you have N_f  IPMP aware routers in the forward path and N_r in 
the reverse one. Starting from a situation where only the echoing router 
inserts a path record (and where we measure of a delay D_f_0 in the 
forward path and D_r_0 in the rewerse one), one could selectively 
activate the measurements on some of them, measure a  D_f_ 1 and  D_r_1, 
then further increase the percentage of IPMP routers allowed to insert 
path records, etc.
Ideally, if all the  IPMP aware routers complied to the mentioned sec. 
4.4 requirement

  "A forwarding system SHOULD NOT insert a path record if it
   cannot modify the packet in the same processing stream that any
   other packet would take.  This is to avoid the measurement path
   being significantly different than that taken by a regular packet,
   and to reduce opportunities for denial of service attacks (see
   Section 4.5)."

then all D_f_i = D_f_0 (*) for all i, and similarly for the reverse 
path. Otherwise, by repeating multiple tests, the critical routers could 
be found. 
(*) equal accoding to some statistical test, to be defined.

Of course, these tests would be only useful to evidence if an IPMP aware 
router takes much more time to insert a path record than just realize 
it's not allowed to do so and forward the packet. It doesn't say 
anything about how similar the treatment of an IPMP packet is wrt the 
one of a corresponding ordinary packet.

2) In a scenario where a set of mesurements are continuously running 
between several netwok end points, there's no use  in always having a 
full view of the path if the end-to-end performance metric under 
observation is within an admittable range. In case the metric breaks a 
threshold, one could immagine to gradually increase the number  of IPMP 
routers along the path inserting path records. Non-affected paths 
wouldn't place additional measurement burden on IPMP routers.

As regards the implementation of such a selection, one can immagine 
different possibilities, trading off simplicity and selectivity.
E.g. putting two explicit 1 byte start/end indexes in the IPMP header 
(an IPMP router can write a path record only if the TTL of the packet is 
within the range) or using a very few bits (an IPMP can write a paket 
only if the TLL ends with the same bit pattern).   

> 3) Host Processing, Raw Sockets or Ports
>
> Is is a requirement of IMP that applications/servers send and receive
> IMP packets over raw sockets or should port numbers to be provided to
> allow the use of bound sockets? While there may be performance
> concerns that would recommend against raw sockets I think the security
> implications are probably more compelling. Generally raw sockets
> require root/administrative privileges to open. This greatly limits
> the deployment options for experimenting with IMP applications;
>
> http://www.merit.edu/mail.archives/nanog/2001-02/msg00829.html
>
> If the OS did not require such privileges then any application on the
> host can send/receive IMP packets greatly complicating the job of
> firewalls. If IMP has port numbers (and there is a 'well known' echo
> port) if a site ensures that a trusted echo server is bound to the
> well known port on all its hosts then it can configure its firewalls to
> only allow in traffic to the well known port, without providing a
> covert channel through the firewall.
>
> Also having ports would allow operators to run private echo servers on
> non-well known ports which would make them less vulnerable to DOS
> attacks (demuxing on port numbers being much more efficient than by
> pattern matching filters). (if the private servers only echoed packets
> from the local subnet/NOC hosts/containing a special 'cookie' then the
> private server could not be found by port scanning.
>
> Finally since having port numbers does not preclude using raw sockets
> if that is desired, but not having them requires it, it would seem
> that IMP should have port numbers.
>
>
>
> 4) IP Address in Path Record
>
> Should IMP require that devices put their IP address in the path record?
> If by IP address we mean a "globally routable IP address", then the
> answer would have to be "No" since routers behind a firewall/NAT only
> have a private IP address, but we would not want them to be unable to
> insert a path record because of this. Additionally it is easy to see
> for security reasons that a site may not wish to reveal the topology
> of the network behind its firewall (and an ISP may not wish to reveal
> the topology of the interior of its network) but that does not mean we
> don't want to know about the existence and/or properties of devices on
> the path.
>
> If we don't require IP addresses what do we require? AS numbers? If
> you have one that would be reasonable. If not, then what? Requiring
> some sort of 'unique' ID probably raises the issue of topology
> discovery again. So it would seem that IMP should not require any
> address at all to be in the path record (except AS num if
> applicable).
>
> In general one would want devices to put an IP address in the record if
> possible, but the protocol must work if they do not. 

>
> 5) Timestamp in Path Record
>
> Must IMP require that a timestamp always be included in the path
> record? Probably not. Without the timestamp the path record is static
> but for the 8 bit TTL making the incremental checksum update much
> easier.

> It is also possible that in existing equipment for which IMP
> support is added that there is no clock available at the location
> where path records are inserted. Now in the case where the device can
> not insert a timestamp do we require the timestamp field to be
> included (0 filled?) or do we allow it to be omitted? If the timestamp
> field is omitted then more records can fit in a packet. In the case
> where IMP is being used as (reverse) traceroute it might make sense to
> allow the sender to request the omission of the timestamp for this
> reason. Obviously the desired behavior in the general case is for
> there to be a timestamp if possible and desired by the sender.
>
>
> 6) TTL in the path record
>
> Should path records be required to contain the TTL value of the packet
> when the record is inserted? I believe that the answer is "Yes". It
> will be a long time before all devices implement IMP, understanding
> which hops in the path have inserted records will be very important
> for understanding how useful the returned information is. A good
> example would be were a packet crosses from one ISP to another, being
> able to determine that there are no unrecorded hops between the last
> record from ISP A, and the first from ISP B allows the packet to serve
> as a valid measurement of the two separate networks. If there might be
> an unknown device between the two measurements then it would not be
> possible to know where one ISP's network ended and the others began.
> Since the TTL occurs very early in the IP packet and is only 8 bits
> the effort required to support it in the checksum update is minimal
> compared to the benefit of having it.
>
>
>
> 7) Information Request Required
>
> Is the information request packet required? Will the protocol work
> without it? I would argue that the information request packet can not
> be required and that the protocol must work without it. There are a
> number of reasons for this. Firstly having identified that we can not
> require that path records contain a globally routable IP address, if
> the information request packet is required for proper operation then
> the protocol is already broken for all routers behind a
> firewall/ALG/NAT. Secondly since the information request requires more
> processing effort than an echo request it is highly unlikely that a
> router will be able to process even close to as many info requests per
> second as echo requests. If each echo request requires an info request
> then the info request may have to be sent repeatedly to get an answer
> back, further increasing the load on router. Thirdly since the info
> request is harder to process it provides a DOS attack against the IMP
> echo protocol, i.e. you attack the point of service for the info
> requests which renders the echo requests unusable

> While it may be allowed so it can provide useful additional features 
> it does not seem
> that the Information Request can be required for proper operation of
> the protocol. 

My understanding of the role of the Information Request in
 http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt
is that it  is  used to get better confidence of what the echo request 
packet carry. There's no reqirement for Information Request to be 
processed like ordinary data packet, and in sec. 4.5 it's said that a 
rate limitation or a low processing prioriy can be used as a protection 
from potential DoS attacks exploiting the Information Request.
I agree, however, that the protocol should not make Echo Requests depend 
on Information Request, i.e. the protocol should work anyway in absence 
or with a low rate of Information Requests (but an application could 
then declare the measurements as "unreliable").

>
>
>
> 8)Information Request part of IMP or a UDP Based Service
>
> Should the information request be part of IMP itself or should it be
> just a protocol exchanged over a UDP port? The only example of a need
> for the information request to be part of IMP that I have come up with
> would be in the case of a broken reverse path (and assuming a yes
> answer to #9 below) that one could use IMP redirection to be able to
> get a response to an info request from hosts and routers on the
> reverse path. It is not clear to me this is enough of a reason to
> include it in the protocol itself as opposed to specifying it as a UDP
> based service.
>
>
> 9) Redirection
>
> Does IMP need a redirection function similar to the IP Loose Source
> Route option? Yes it does. For IMP to be useful in the context of
> network operations the ability to bounce the echo request off of other
> routers and hosts is clearly required, for an explanation see;
>
> http://www.merit.edu/mail.archives/nanog/2002-02/msg00247.html
>
> That the redirection should be built into IMP can be derived from two
> points, firstly it allows us to include security measures not present
> in LSRR which eliminate some of the spoofing concerns people have with
> the general availability of LSRR. Second since the processing of
> packets with IP options is often not in the same path as un-option-ed
> packets it would interfere with the desired operation of IMP to use
> source routing headers. Thirdly when trying to trace the path taken by
> packets belonging to an application, if the IMP packet contained header
> options then it would be very likely to not match any application
> specific filters, or to have a different hash value when picking the
> output link in the case of ECMP routing. Fourth, without redirection
> there is no way to probe a broken reverse path. So it seems the
> redirection is required and that it must be supported within the
> protocol itself.
>
>
>
> _______________________________________________
> IMRG mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/imrg

_______________________________________________
IMRG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imrg

---

From: Matthew Luckie <[email-masked]>
Date: Fri, 5 Dec 2003 09:07:38 +1300 (NZDT)

> > always filling the packet is needed, otherwise only the first N hops

A comment on this, taken from our IMW2001 paper:

http://www.icir.org/vern/imw-2001/imw2001-papers/85.pdf

"The minimum packet size that must be supported by an IP network, 576
bytes, allows for 45 path records to be stored in an echo request packet.
The size of the path record would increase to 24 bytes in an IPv6
environment due to the storage requirements of a 16 byte address.
In an IPv6 environment, the Minimum Transmission Unit (MTU) of 1280 bytes
[RFC 2460] allows for 50 path records to be inserted in an echo packet.
Research from CAIDA's Skitter project

http://www.caida.org/tools/measurement/skitter/RSSAC/

indicates that the average distance between the F root server (at ISC in
1999) and a  customer of that server is 13 hops, while less than 0.5% of
paths are longer than 22 hops.  For a path connecting a pair of hosts that
is longer than can be measured with the MTU-sized packet, a measurement
host may restart the measurement from one of the last IP addresses in the
path record by sending an echo request to an address that will answer the
request (if there is such an address), or by sending a larger packet if
the underlying network supports the increased size of the packet."

so i'd respond that this feature is not something that is necessary.  In
practice, I'd imagine the vast majority of paths can handle more than 576
bytes.

http://www.netsys.com/ietf/1994/1280.html

You can fit about 120 IPv4 path records in a 1500 byte IP packet.

> only if the TLL ends with the same bit pattern).

other approaches include laying out path records which are blanked out
except for the TTL field, which are set to whatever TTLs you're interested
in.

I don't think this buys us anything, the whole "tightly constrained and
easy to implement" argument goes out the window, and becomes non compliant
with point 12 of RFC 1925

> from potential DoS attacks exploiting the Information Request.

This is correct.

> then declare the measurements as "unreliable").

The utility of the Information Request is largely underestimated.  The
protocol will largely work, although you'll be without some useful data.
We're working on expanding the information request section for -04.txt to
better illustrate the usefulness of it.

Matthew

---

From: Maurizio Molina <[email-masked]>
Date: Fri, 05 Dec 2003 11:19:21 +0100

Matthew Luckie wrote:

>path record by sending an echo request
>
This I didn't understand. Does the current protocol specification allow 
to start the measurement from an arbitrary point of the path? This would 
of course (almost) solve the problem we're discussing about....  

> to an address that will answer the
The numbers you brought are convincing that there'll be room for path 
records in "the vast majority of the paths" (we then may discuss whether 
this is enough, and I would agree that yes, it is enough and not worth 
complicating the protocol for that reason only...).
However, in my previous message I brought two other reasons for which 
the flexibility of selectively letting a router fill in a path record 
could be useful, namely 1) the possibility of discovering "bad" IPMP 
implementations and 2) reducing the measurement load brought by non 
congested paths.
Could you comment on these?

>except for the TTL field, which are set to whatever TTLs you're interested
Once again I didn't clearly understand this, sorry. Are you suggesting 
that the path record format can be NOT fixed (i.e.12 bytes IPv4, 24 
bytes IPv6)? Then where is the lenght of the path record encoded? I 
think that Jon brought up exactly this point in his original message of 
this thread: It was "5) Timestamp in Path Record"

>with point 12 of RFC 1925
which is always a good rule to follow, provided pro and cons of 
adding/excluding features have been discussed....
Maurizio

---

From: jon bennett <[email-masked]>
Date: Sat, 06 Dec 2003 23:28:13 -0800

>Isn't there the same problem if the break is in the "forward" path?

No in the case of a break in the forward path, there is no problem in 
returning a packet from the point of the break. In the case of a break in 
the reverse direction the packet will be on the other side of the break and 
be unable to return directly to the sending host.

It would be best if the TTL=0 behavior of routers was to return the IMP 
packet rather than to return an ICMP packet. In the backward path case this 
almost required to make things work   without a lot of extra effort.

>packets were processed

Actually the easiest way to determine if this is the case would be the path 
record flag in my draft in which the router explicitly indicates if the 
processing occurred in the fast path or not.

Anything else is just a guess that the delay increase is due to slow path 
processing. Now with repeated probing you may improve the statistical 
accuracy of that guess, but you could not be certain.

>(requirement of 
>forward path and D_r_0 in the rewerse one), one could selectively activate 
>the measurements on some of them, measure a  D_f_ 1 and  D_r_1, then 
>further increase the percentage of IPMP routers allowed to insert path 
>records, etc.

The problem with this approach is that it assumes the delay of each 
component of the path is fixed while you are performing the test, if the 
delay varies as you add more routers to be measured you cant be sure if the 
delay went up because of non-fast path processing, or just because there 
was queuing delay (or because it is a software router and the processing of 
every packet may vary with load).

>Ideally, if all the  IPMP aware routers complied to the mentioned sec. 4.4 
>requirement
>

Actually this is hardly ideal, it will be a long long time before all 
routers would process IMP in the fast path. Only permitting routers to 
insert path records if they can do so in the fast path will greatly limit 
the routers which can be detected by IMP. The is particularly true if you 
are probing for the components of the path or any non-timing related 
properties of the path in which case you don't care at all if the 
processing is performed in the slow path. Which is why my draft contains a 
flag for indicating if the sender wants only fast path processing of the 
packet or not. If you care about timing you set the flag and the packet is 
either processed in the fast path or it is left untouched, if you don't set 
the flag the packet may be processed in the slow path. In the later case 
the path record will have the flag set which indicates that the packet was 
handled in the slow path (if it was handled in the slow path).

>between several netwok end points, there's no use  in always having a full 
>view of the path if the end-to-end performance metric under observation is 
>within an admittable range.

....

>E.g. putting two explicit 1 byte start/end indexes in the IPMP header (an 
>IPMP router can write a path record only if the TTL of the packet is 
>within the range) or using a very few bits (an IPMP can write a paket only 
>if the TLL ends with the same bit pattern).

Yes I had considered such a mechanism for this reason but had not included 
it since I anticipated it would just result in more complaints about 
complexity from certain parties. The case of having the packet be stamped 
only if the TTL ends in a given bit pattern would be more useful than the 
if the TTL is within a range since after you detected an increase in an 
end-to-end property you might have to move the range around for a while 
before you found the hop responsible. If you had a stamp at even spacing 
along the path then you would be able to determine the range in which the 
trouble was being caused immediately.

>>  Thirdly since the info

....

>packet carry.

No, unlike in my draft the timestamps in the mcgregor draft contain no 
information at all to tell you anything about their accuracy or how to 
convert them to UTC timestamps, as such they are basically useless without 
the results of information request message. Without knowing how to convert 
to UTC you can't use the mcgregor timestamps for delay measurement, and 
without knowing the clock source stability, or accuracy of the clock and/or 
timestamping process you can't even use it for jitter measurement.

Additionally since the mcgregor draft does not provide for getting 
additional information (MTU, ASN, Link Speed, etc) in the echo request, the 
information request is the only way to find out those properties.

>There's no reqirement for Information Request to be processed like 
>ordinary data packet, and in sec. 4.5 it's said that a rate limitation or 
>a low processing prioriy can be used as a protection from potential DoS 
>attacks exploiting the Information Request.

I do not think you understood what I said, I was not saying that the 
information request message was a DOS attack against the router (well it is 
but it can be mitigated by processing them at low priority, or with rate 
limiting), what I said was the information request can be a DOS attack 
against the ECHO REQUEST as a by product of the router protecting itself 
from being DOSed by information requests. If I pound a router with info 
requests then the number of legitimate info requests that get processed 
goes way down. Now someone trying to get timestamp information or anything 
else with an info request may have to send their many times before they get 
an answer. This of course just adds to the loading on the router.

>on Information Request, i.e. the protocol should work anyway in absence or 
>with a low rate of Information Requests (but an application could then 
>declare the measurements as "unreliable").

Aside from asking what good an "unreliable" measurement is, would it not be 
better just to design the protocol so that this was not such a problem in 
the first place?

---

From: jon bennett <[email-masked]>
Date: Sat, 06 Dec 2003 23:52:21 -0800

>bytes, allows for 45 path records to be stored in an echo request packet.

This totally ignores the case where you want to measure the performance 
along a path as seen from the point of view of an application, such as a 
VoIP call. For instance, by replacing a silence suppressed packet with an 
IMP packet, where you will want to (and in some cases due to policing, will 
have to) send a packet the same size as the RTP voice packet. I should 
mention that the policing requirement is not fanciful, if your VoIP call is 
coming from a cable modem the IMP packet is going to have to be the same 
size as the RTP packet it is replacing or it will either get dropped or it 
will take as long to transmit as the number of RTP packets its size is a 
multiple of, resulting in the delaying of all the real RTP   packets 
following it. If the VoIP call is using G.711 coding you will no more than 
120 bytes for path records, which means 10 path records, that gets you a 4 
hop path assuming the hosts only stamp once, if they stamp twice (RX and 
TX, which they should do if you want to remove host processing from the 
measurements) you get a 3 hop path. And of course you better hope they 
don't want to measure a G.729 call, where you would have 20 bytes for path 
records, or should I say of the ONE path record. Obviously there are other 
protocols where one might want to measure along a path I bring up VoIP as 
the obvious example of a timing dependant protocol using small packets.

>1999) and a  customer of that server is 13 hops,

It is hardly surprising that in the Internet of 4 years ago a major 
research institute located in California would have good connectivity to 
most of the rest of the world.

Last night I played around with a few looking glass servers and it was 
pretty easy to find path lengths from one looking glass server to another 
with lengths of 25-30, which would be 50-60 path records. Since  the 
looking glass machines tend to me located in data centers or NOCs one 
should add a few more hops for average customer machines

>while less than 0.5% ofpaths are longer than 22 hops.

arguments like are a perfect example of incorrect use of statistics for 
system design. it is not that "only 0.5% of the path measurements performed 
are longer than 22 hops" but that "only 0.5% of the paths measured were 
longer than 22 hops", if the path you want to measure happens to be one of 
those then 100% of your path measurements will fail because the path is too 
long.

It occurred to me that my comment above about easily finding paths with 
lengths of 25-30 in length might not be strong enough by itself and I want 
to make to transparently obvious that making assumptions about path lengths 
being "short enough" is just a refusal to except reality. So after getting 
back from dinner with my relatives (who I'm visiting at the moment, hence 
my delay in responding to this message) I plugged my laptop into my uncle's 
cable modem and started tracing the path from various traceroute servers 
back to my machine.

To get the full effect I am going to include full traces here because, as I 
said, I want to make this transparently clear that trying to pretend that 
data from 1999 tells to anything about the size of todays network (4 years 
later), or that the size of todays network tells to about the connectivity 
of the network in 2007 (4 years from now) is just wishful thinking.

In case you get board of reading I will give you the "punch line" now, the 
last trace terminated 2 hops short of my machine having already reached the 
default limit of 30 hops! The full list includes traces of length 24, 25, 
26, 27, two of length 30 and the already mentioned one of length 32. And as 
I mentioned before these were from traceroute servers so one can only 
imagine that if the path were taken to a customer machine in the ISP 
hosting the server that the path would be a few more hops in length.

(I have included the URL of the traceroute server with each trace in case 
anyone feels the need to try it themselves, although I can only guarantee 
that it will work for the next hour or so until I unplug my laptop and the 
DHCP address gets assigned to someone else)

http://neptune.vqbn.com/lg/networktools.php
1  GE-1-GSR-1 (202.73.32.1)  0.651 ms  0.355 ms  0.349 ms
  2  juniper-m160-2 (202.73.40.1)  0.635 ms  1.013 ms  0.522 ms
  3  203.192.168.209 (203.192.168.209)  95.854 ms  177.219 ms  5.626 ms
  4  pos1-1-0-155M.ar1.SIN1.gblx.net (203.192.163.65)  2.785 ms  3.073 
ms  2.863 ms
  5  pos8-3-155M.cr1.NRT1.gblx.net (203.192.163.30)  77.616 ms  78.136 
ms  77.538 ms
  6  ge12-0-1000M.ar1.NRT5.gblx.net (203.192.145.82)  78.075 ms  78.296 
ms  77.969 ms
  7  ge2-2-0-1000M.br1.NRT2.gblx.net (203.192.145.74)  78.273 ms  78.783 
ms  78.861 ms
  8  203.192.129.42 (203.192.129.42)  78.584 ms  78.683 ms  78.578 ms
  9  pos4-0.mpr2.nrt2.jp.mfnx.net (208.184.233.138)  78.900 ms  78.775 
ms  78.167 ms
10  so-2-1-0.cr2.nrt3.jp.mfnx.net (208.184.210.74)  78.677 ms  78.913 
ms  79.209 ms
11  so-3-2-1.cr1.sjc3.us.above.net (64.125.30.10)  179.231 ms  178.229 
ms  191.941 ms
12  so-7-0-0.mpr3.sjc2.us.above.net (208.185.175.154)  178.831 ms  198.401 
ms  178.300 ms
13  pos5-0.mpr1.pao1.us.mfnx.net (208.184.233.142)  179.602 ms  178.194 
ms  179.186 ms
14  209.249.11.82.adelphiacom.net (209.249.11.82)  178.508 ms  179.725 
ms  179.432 ms
15  p3-00-03-00.r0.sjc75.adelphiacom.net (66.109.3.198)  177.966 
ms  177.928 ms  177.798 ms
16  p3-00-00-00.n0.sjc75.adelphiacom.net (66.109.0.133)  177.831 
ms  178.420 ms  177.668 ms
17  p3-00-01-00.n0.lax91.adelphiacom.net (66.109.0.22)  185.387 ms  185.516 
ms  187.160 ms
18  66.109.0.54 (66.109.0.54)  212.013 ms  211.842 ms  211.962 ms
19  p3-01-00-00.n0.mia95.adelphiacom.net (66.109.0.26)  239.835 ms  239.802 
ms  239.708 ms
20  p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194)  239.939 
ms  239.729 ms  239.904 ms
21  g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222)  239.753 
ms  239.911 ms  239.821 ms
22  g1-03-00-00.ber01.miamfl.adelphia.net (66.109.14.238)  240.136 
ms  240.298 ms  240.203 ms
23  68.168.1.82 (68.168.1.82)  241.943 ms  241.741 ms  241.942 ms
24  67.22.106.30 (67.22.106.30)  242.563 ms  242.210 ms *

http://misu.dc.ro/index.php?src=trace.php
1 brasov-cr-fe1-1.brasov.rdsnet.ro (213.157.185.161) 0.630 ms 0.488 ms 0.466 ms
2 brasov-bb-fe1-0.rdsnet.ro (81.196.37.185) 0.519 ms 0.464 ms 0.744 ms
3 bucuresti1-bb1-ge4-0-0.94.v94.rdsnet.ro (193.231.253.129) 3.252 ms 3.424 
ms 2.952 ms
4 buh1-gsr2-ge4-0.rdsnet.ro (62.231.127.130) 4.541 ms 3.271 ms 4.298 ms
5 fra2-cr1-p6-0.rdsnet.ro (193.231.252.226) 27.719 ms 28.158 ms 27.625 ms
6 fra2-cr2-p2-0.rdsnet.ro (193.231.252.206) 26.288 ms 26.193 ms 26.636 ms
7 de-cix.fra.above.net (80.81.192.226) 26.279 ms 26.349 ms 26.333 ms
8 so-0-1-0.cr2.fra1.de.mfnx.net (216.200.116.209) 29.961 ms 29.931 ms 29.626 ms
9 pos10-0.mpr1.ams1.nl.above.net (64.125.30.150) 36.177 ms 36.289 ms 37.453 ms
10 pos0-0.mpr2.ams1.nl.above.net (208.184.231.182) 35.877 ms 36.455 ms 
36.323 ms
11 pos2-0.cr2.ams2.nl.above.net (208.184.231.254) 36.076 ms 37.613 ms 36.570 ms
12 so-4-0-0.cr2.lhr3.uk.above.net (64.125.31.157) 42.551 ms 41.650 ms 42.047 ms
13 so-7-0-0.cr2.lga1.us.above.net (64.125.31.182) 144.950 ms 146.023 ms 
144.839 ms
14 so-0-0-0.cr2.lga2.us.mfnx.net (208.184.232.198) 146.783 ms 146.306 ms 
145.928 ms
15 core1-lga2-oc48.lga4.above.net (64.124.232.2) 144.169 ms 142.579 ms 
142.832 ms
16 216.200.134.2.adelphiacom.net (216.200.134.2) 144.128 ms 143.885 ms 
144.425 ms
17 g1-01-00-00.r0.nyc90.adelphiacom.net (66.109.1.13) 146.268 ms 146.173 ms 
g1-04-00-00.r0.nyc90
.adelphiacom.net (66.109.1.29) 141.615 ms
18 p3-01-02-00.n0.nyc90.adelphiacom.net (66.109.0.181) 144.075 ms 144.612 
ms 144.220 ms
19 p3-00-01-00.n0.dca91.adelphiacom.net (66.109.0.78) 132.408 ms 132.213 ms 
132.778 ms
20 p3-00-01-00.n0.mia95.adelphiacom.net (66.109.0.38) 178.053 ms 178.796 ms 
178.841 ms
21 p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194) 176.909 ms 176.858 
ms 177.797 ms
22 g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222) 176.879 ms 176.813 
ms 177.090 ms
23 g1-01-00-00.ber01.miamfl.adelphia.net (66.109.14.230) 178.205 ms 177.316 
ms 176.948 ms
24 68.168.1.82 (68.168.1.82) 178.306 ms 178.770 ms 178.735 ms
25 67.22.106.30 (67.22.106.30) 180.706 ms 179.646 ms *

http://www.kcbbs.gen.nz/cgi-bin/trace?68.64.85.126
traceroute to 68.64.85.126 (68.64.85.126), 30 hops max, 40 byte packets
  1  f-1-0.C7206-1.kc.net.nz (202.14.102.13)  0.868 ms  0.598 ms  0.56 ms
  2  FE1-0-0.401-KC-INTNET.ar1.akl1.gblx.net (203.192.166.85)  1.365 
ms  0.881 ms  1.049 ms
  3  at1-1-0-34-155M.ar1.SYD1.gblx.net (203.192.166.10)  26.263 ms  25.618 
ms  25.91 ms
  4  ge0-0-0-0.cr1.SYD1.gblx.net (203.192.160.101)  25.855 ms  25.689 
ms  25.823 ms
  5  pos13-0-155M.cr1.NRT1.gblx.net (203.192.136.78)  139.008 ms 
so2-0-0-622M.cr2.NRT1.gblx.net (203.192.128.205)  138.791 ms  140.028 ms
  6  ge1-2-0-1000M.ar2.NRT5.gblx.net (203.192.145.86)  140.084 ms  140.091 
ms ge12-0-1000M.ar1.NRT5.gblx.net (203.192.145.82)  140.136 ms
  7  ge2-2-0-1000M.br1.NRT2.gblx.net (203.192.145.74)  139.643 ms  140.399 
ms  139.489 ms
  8  203.192.129.42 (203.192.129.42)  140.772 ms  139.352 ms  140.641 ms
  9  so-2-1-0.cr1.nrt3.jp.mfnx.net (208.184.210.30)  140.623 ms  140.292 
ms  145.242 ms
10  so-1-0-0.cr2.nrt3.jp.above.net (64.125.31.82)  141.066 ms  140.74 
ms  139.979 ms
11  so-3-2-1.cr1.sjc3.us.above.net (64.125.30.10)  191.011 ms  190.154 
ms  189.677 ms
12  so-7-0-0.mpr3.sjc2.us.above.net (208.185.175.154)  190.72 ms  190.591 
ms  190.382 ms
13  pos5-0.mpr1.pao1.us.mfnx.net (208.184.233.142)  190.657 ms  190.564 
ms  189.821 ms
14  209.249.11.86.adelphiacom.net (209.249.11.86)  190.251 ms  190.513 
ms  190.748 ms
15  p3-00-03-00.r0.sjc75.adelphiacom.net (66.109.3.198)  190.013 
ms  190.146 ms  190.017 ms
16  p3-00-00-00.n0.sjc75.adelphiacom.net (66.109.0.133)  189.744 
ms  189.714 ms  189.666 ms
17  p3-00-01-00.n0.lax91.adelphiacom.net (66.109.0.22)  197.002 ms  197.752 
ms  197.329 ms
18  66.109.0.54 (66.109.0.54)  223.515 ms  222.922 ms  223.315 ms
19  p3-01-00-00.n0.mia95.adelphiacom.net (66.109.0.26)  251.959 ms  251.618 
ms  251.716 ms
20  p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194)  251.221 
ms  251.387 ms  250.59 ms
21  g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222)  252.062 
ms  252.604 ms  252.101 ms
22  g1-03-00-00.ber01.miamfl.adelphia.net (66.109.14.238)  253.969 
ms  251.369 ms  251.812 ms
23  68.168.1.82 (68.168.1.82)  267.845 ms  254.046 ms  253.46 ms
24  67.22.106.30 (67.22.106.30)  254.392 ms 68.168.1.82 
(68.168.1.82)  253.681 ms  252.664 ms
25  67.22.106.30 (67.22.106.30)  254.356 ms  255.167 ms  254.855 ms
26  fl-pbg1-f0.pbc.adelphia.net (24.49.23.69)  253.79 ms  255.133 
ms  254.199 ms

http://home.pl/trace/
HOST                                    LOSS  RCVD SENT    BEST     AVG   WORST
gate-wa.home.net.pl                       0%     5    5    0.38    0.47    0.60
gate.home.net.pl                          0%     5    5    0.83   22.97  110.63
do-homenet.ipartners.pl                   0%     5    5    0.88    1.13    1.32
217.153.2.38                              0%     5    5    1.24    1.45    1.78
war-p2r1-g8-0-310.ipartners.pl            0%     5    5    1.45    1.56    1.82
fra-tr1-p0-1-0.gtsce.net                  0%     5    5   25.84   27.07   28.77
de-cix.fra.above.net                      0%     5    5   25.87   26.16   26.59
so-0-1-0.cr2.fra1.de.mfnx.net             0%     5    5   26.20   26.41   26.74
pos10-0.mpr1.ams1.nl.above.net            0%     5    5   32.34   32.77   33.00
pos2-0.cr1.ams2.nl.above.net              0%     5    5   33.23   33.61   34.43
pos3-0.cr2.ams2.nl.above.net              0%     5    5   32.96   33.35   33.87
so-4-0-0.cr2.lhr3.uk.above.net            0%     5    5   40.01   40.32   40.74
so-7-0-0.cr2.lga1.us.above.net            0%     5    5  141.51  142.03  143.12
so-0-0-0.cr2.lga2.us.mfnx.net             0%     5    5  142.45  142.66  142.76
core1-lga2-oc48.lga4.above.net            0%     5    5  142.67  142.94  143.33
216.200.134.2.adelphiacom.net             0%     5    5  138.17  138.41  138.76
g1-04-01-00.r0.nyc90.adelphiacom.net      0%     5    5  138.77  152.25  155.91
p3-01-02-00.n0.nyc90.adelphiacom.net      0%     5    5  138.39  151.98  155.73
p3-00-01-00.n0.dca91.adelphiacom.net      0%     5    5  136.50  136.79  137.64
p3-00-01-00.n0.mia95.adelphiacom.net      0%     5    5  162.49  162.77  163.12
p3-00-00-00.r0.mia95.adelphiacom.net      0%     5    5  162.22  162.58  163.41
g1-00-00-00.a0.mia95.adelphiacom.net      0%     5    5  181.57  181.94  183.04
g1-02-00-00.ber01.miamfl.adelphia.net     0%     5    5  162.33  162.50  162.67
68.168.1.82                               0%     5    5  182.88  183.21  183.74
67.22.106.30                              0%     5    5  165.05  165.23  165.38
fl-pbg1-f0.pbc.adelphia.net               0%     5    5  164.75  165.50  166.25

http://www.satori.net.au/cgi-bin/newtrace
#  1 gw (203.21.11.254) 1.200 ms 0.979 ms 0.848 ms
# 2 * * *
# 3 g5-0-0-2.tungsten.adnap.net.au (203.2.124.146) 1899.132 ms 336.043 ms 
1820.832 ms
# 4 FastEthernet1-0-0.GW1.ADL1.ALTER.NET (203.166.92.105) 1943.433 ms 
437.042 ms 2089.940 ms
# 5 321.AT-3-0-0.XR1.ADL1.ALTER.NET (210.80.32.137) 1440.402 ms 2108.421 ms 
1979.921 ms
# 6 0.SO-0-1-0.XR2.SYD2.ALTER.NET (210.80.33.221) 2110.989 ms 2256.375 ms 
2270.269 ms
# 7 so-3-0-0.TR2.SYD2.Alter.Net (210.80.48.145) 1261.242 ms 2151.453 ms 
1655.972 ms
# 8 0.so-5-0-0.IR2.SAC2.Alter.Net (210.80.49.61) 1647.649 ms 1229.285 ms 
1479.310 ms
# 9 POS3-0.IR2.SAC1.ALTER.NET (137.39.31.210) 899.173 ms 308.334 ms 470.396 ms
# 10 0.so-4-1-0.TL2.SAC1.ALTER.NET (152.63.0.118) 2249.074 ms 2109.055 ms 
1969.346 ms
# 11 0.so-7-0-0.XL2.SAC1.ALTER.NET (152.63.54.9) 849.926 ms 923.777 ms 
1820.601 ms
# 12 POS7-0.BR6.SAC1.ALTER.NET (152.63.53.5) 2269.035 ms 2374.225 ms 
2224.271 ms
# 13 204.255.168.70 (204.255.168.70) 2239.422 ms 2340.385 ms 1908.454 ms
# 14 so-4-3-0.mpr3.sjc2.us.above.net (64.125.30.29) 2199.503 ms 2156.680 ms 
2199.953 ms
# 15 pos5-0.mpr1.pao1.us.above.net (208.184.233.142) 2342.875 ms 1405.776 
ms 2172.844 ms
# 16 209.249.11.86.adelphiacom.net (209.249.11.86) 1839.484 ms 1901.087 ms 
2147.232 ms
# 17 p3-00-03-00.r0.sjc75.adelphiacom.net (66.109.3.198) 2159.989 ms 
2137.856 ms 2187.725 ms
# 18 p3-00-00-00.n0.sjc75.adelphiacom.net (66.109.0.133) 1931.512 ms 
410.378 ms 527.867 ms
# 19 p3-00-01-00.n0.lax91.adelphiacom.net (66.109.0.22) 979.537 ms 1898.722 
ms 2150.740 ms
# 20 p3-00-02-00.n0.dfw91.adelphiacom.net (66.109.0.54) 1949.026 ms 
2472.915 ms 2466.704 ms
# 21 p3-01-00-00.n0.mia95.adelphiacom.net (66.109.0.26) 2208.662 ms 
2699.796 ms 2219.221 ms
# 22 p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194) 2249.858 ms 
2119.370 ms 1009.498 ms
# 23 g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222) 1859.105 ms 
2098.232 ms 2199.764 ms
# 24 g1-00-00-00.ber01.miamfl.adelphia.net (66.109.14.226) 2009.278 ms 
2547.994 ms 2360.192 ms
# 25 68.168.1.82 (68.168.1.82) 2229.122 ms 2158.537 ms 2430.043 ms
# 26 67.22.106.30 (67.22.106.30) 2249.917 ms 1219.609 ms 1412.074 ms
# 27 fl-pbg1-f0.pbc.adelphia.net (24.49.23.69) 1060.382 ms 2149.062 ms 
2196.593 ms

http://www.drbit.com.ru/cgi/nph-traceroute?tracehost=24.49.23.65
traceroute to 24.49.23.65 (24.49.23.65), 30 hops max, 40 byte packets
  1  router (81.176.192.62)  1.961 ms  2.001 ms  1.950 ms
  2  nsk-car3-se1-0.rt-comm.ru (217.106.20.165)  11.150 ms  16.842 
ms  10.451 ms
  3  217.106.21.254 (217.106.21.254)  11.828 ms  10.955 ms  15.255 ms
  4  kochenevo-bbn0-po3-2.rt-comm.ru (217.106.6.133)  127.807 ms  127.543 
ms  125.666 ms
  5  tschelkun-bbn0-po1-1.rt-comm.ru (217.106.6.129)  128.196 ms  130.339 
ms  125.970 ms
  6  shigony-bbn0-po2-2.rt-comm.ru (217.106.6.121)  116.020 ms  128.071 
ms  125.631 ms
  7  msk-bbn0-po3-0.rt-comm.ru (217.106.7.57)  128.191 ms  127.477 
ms  126.335 ms
  8  lnd-bgw0-po1-0-0-0.rt-comm.ru (217.106.6.166)  114.494 ms  113.556 
ms  111.283 ms
  9  POS2-0.GW1.LND9.ALTER.NET (146.188.66.49)  135.044 ms  139.849 
ms  122.164 ms
10  ge5-0.cr1.lnd8.gbb.uk.uu.net (158.43.188.1)  113.803 ms  112.308 
ms  111.456 ms
11  sc-7-0-0.xr1.lnd9.alter.net (158.43.150.98)  151.218 ms  616.406 
ms  176.059 ms
12  so-0-1-0.TR2.LND9.ALTER.NET (146.188.15.41)  149.138 ms  113.813 
ms  113.032 ms
13  POS2-0.BR1.LND9.ALTER.NET (146.188.7.246)  123.968 ms  124.417 
ms  125.173 ms
14  pos3-1-oscar.LON.COLT.NET (146.188.57.98)  125.792 ms  125.244 
ms  151.472 ms
15  pos8-3.mpr1.lhr1.uk.above.net (208.185.188.37)  124.286 ms  124.306 
ms  122.867 ms
16  so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174)  113.071 ms  129.904 
ms  212.947 ms
17  so-0-0-0.cr2.lhr3.uk.above.net (208.184.231.146)  112.032 ms  112.195 
ms  111.157 ms
18  so-7-0-0.cr2.lga1.us.above.net (64.125.31.182)  195.687 ms  193.675 
ms  192.464 ms
19  so-0-0-0.cr2.lga2.us.mfnx.net (208.184.232.198)  190.015 ms  190.213 
ms  189.936 ms
20  core1-lga2-oc48.lga4.above.net (64.124.232.2)  190.243 ms  223.370 
ms  392.597 ms
21  216.200.134.2.adelphiacom.net (216.200.134.2)  238.543 ms  237.956 
ms  259.735 ms
22  g1-01-00-00.r0.nyc90.adelphiacom.net (66.109.1.13)  227.248 ms  789.817 
ms  249.825 ms
23  p3-01-02-00.n0.nyc90.adelphiacom.net (66.109.0.181)  264.245 
ms  229.518 ms  273.961 ms
24  p3-00-01-00.n0.dca91.adelphiacom.net (66.109.0.78)  249.507 ms  222.392 
ms  216.825 ms
25  p3-00-01-00.n0.mia95.adelphiacom.net (66.109.0.38)  259.870 ms  267.810 
ms  304.131 ms
26  p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194)  251.716 
ms  593.338 ms  342.834 ms
27  g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222)  259.614 
ms  330.239 ms  341.079 ms
28  g1-02-00-00.ber01.miamfl.adelphia.net (66.109.14.234)  252.189 
ms  252.885 ms  252.543 ms
29  68.168.1.82 (68.168.1.82)  356.293 ms  264.115 ms  273.996 ms
30  67.22.106.30 (67.22.106.30)  756.766 ms  254.037 ms *

http://nic.dn.ua/cgi-bin/trace?68.64.85.126
traceroute to 68.64.85.126 (68.64.85.126), 30 hops max, 40 byte packets
  1  noc.dn.ua (194.44.61.66)  0.957 ms  0.75 ms  0.546 ms
  2  dipt.ix.dn.ua (194.44.65.101)  1.638 ms  1.503 ms  1.277 ms
  3  dipt-gw.donbass.net (195.184.192.10)  2.447 ms  2.127 ms  2.139 ms
  4  217.106.22.209 (217.106.22.209)  324.91 ms  324.37 ms  324.858 ms
  5  aksai-bbn0-po2-0.rt-comm.ru (217.106.6.105)  325.456 ms  325.649 
ms  328.005 ms
  6  msk-bbn0-po3-2.rt-comm.ru (217.106.6.81)  325.291 ms  325.08 
ms  325.976 ms
  7  lnd-bgw0-po1-0-0-0.rt-comm.ru (217.106.6.166)  324.758 ms  324.579 
ms  324.332 ms
  8  POS2-0.GW1.LND9.ALTER.NET (146.188.66.49)  325.465 ms  324.844 
ms  325.222 ms
  9  ge5-0.cr1.lnd8.gbb.uk.uu.net (158.43.188.1)  325.109 ms  325.35 
ms  324.485 ms
10  sc-7-0-0.xr1.lnd9.alter.net (158.43.150.98)  330.634 ms  325.065 
ms  324.75 ms
11  so-0-1-0.TR2.LND9.ALTER.NET (146.188.15.41)  325.807 ms  324.946 
ms  325.211 ms
12  POS2-0.BR1.LND9.ALTER.NET (146.188.7.246)  325.25 ms  325.507 
ms  327.412 ms
13  pos3-1-oscar.LON.COLT.NET (146.188.57.98)  334.375 ms  334.475 
ms  334.741 ms
14  pos8-3.mpr1.lhr1.uk.above.net (208.185.188.37)  328.667 ms  328.716 
ms  327.78 ms
15  so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174)  329.312 ms  329.18 
ms  328.244 ms
16  so-0-0-0.cr2.lhr3.uk.above.net (208.184.231.146)  330.34 ms  329.123 
ms  328.747 ms
17  so-7-0-0.cr2.lga1.us.above.net (64.125.31.182)  435.843 ms  430.304 
ms  430.578 ms
18  so-0-0-0.cr2.lga2.us.mfnx.net (208.184.232.198)  434.353 ms  432.244 
ms  430.463 ms
19  core1-lga2-oc48.lga4.above.net (64.124.232.2)  430.412 ms  431.359 
ms  429.947 ms
20  216.200.134.2.adelphiacom.net (216.200.134.2)  431.425 ms  431.163 
ms  435.337 ms
21  g1-04-01-00.r0.nyc90.adelphiacom.net (66.109.1.25)  430.725 ms 
g1-01-00-00.r0.nyc90.adelphiacom.net (66.109.1.13)  434.445 ms  431.619 ms
22  p3-00-00-00.n0.nyc90.adelphiacom.net (66.109.0.169)  430.254 ms  431.12 
ms p3-01-02-00.n0.nyc90.adelphiacom.net (66.109.0.181)  430.538 ms
23  p3-00-01-00.n0.dca91.adelphiacom.net (66.109.0.78)  436.526 ms  435.458 
ms  435.33 ms
24  p3-00-01-00.n0.mia95.adelphiacom.net (66.109.0.38)  477.15 ms  476.871 
ms  476.824 ms
25  p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194)  477.977 
ms  476.718 ms  476.25 ms
26  g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222)  477.419 
ms  476.674 ms  476.566 ms
27  g1-01-00-00.ber01.miamfl.adelphia.net (66.109.14.230)  477.288 
ms  476.65 ms  476.474 ms
28  68.168.1.82 (68.168.1.82)  479.948 ms  478.509 ms  478.459 ms
29  67.22.106.30 (67.22.106.30)  479.045 ms  479.414 ms  478.706 ms
30  fl-pbg1-f0.pbc.adelphia.net (24.49.23.69)  478.896 ms  478.977 
ms  478.52 ms

http://www.nlcv.bas.bg/cgi-bin/trace.cgi
  1  router (195.96.248.3)  0.911 ms  0.744 ms  0.697 ms
  2  bas-math.math.bas.bg (195.96.243.1)  1.494 ms  1.537 ms  1.451 ms
  3  213.191.192.1 (213.191.192.1)  1.341 ms  1.375 ms  1.305 ms
  4  backbone.acad.bg (194.141.0.1)  1.442 ms  1.452 ms  1.399 ms
  5  62.75.33.233 (62.75.33.233)  17.656 ms  17.585 ms  17.544 ms
  6  * * *
  7  62.75.33.246 (62.75.33.246)  17.447 ms  18.971 ms  17.16 ms
  8  athens-3-athens-2.grnet.gr (194.177.209.21)  17.442 ms  17.445 
ms  17.364 ms
  9  grnet.gr1.gr.geant.net (62.40.103.57)  17.326 ms  17.301 ms  17.436 ms
10  gr.de2.de.geant.net (62.40.96.94)  94.339 ms  94.392 ms  94.499 ms
11  de2-2.de1.de.geant.net (62.40.96.54)  94.141 ms  94.323 ms  94.179 ms
12  so-7-0-0.ar2.FRA2.gblx.net (208.48.23.145)  94.302 ms  94.289 ms  94.184 ms
13  pos5-0-2488M.cr2.FRA2.gblx.net (67.17.65.53)  94.2 ms  95.058 ms  95.756 ms
14  so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38)  110.269 ms  111.807 
ms  110.386 ms
15  so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30)  118.818 ms  119.723 
ms  118.749 ms
16  902.ge6-1.mpr1.lhr1.uk.above.net (208.185.188.65)  96.43 ms  96.677 
ms  96.733 ms
17  so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174)  95.142 ms  95.098 
ms  95.07 ms
18  so-0-0-0.cr2.lhr3.uk.above.net (208.184.231.146)  95.361 ms  96.614 
ms  95.661 ms
19  so-7-0-0.cr2.lga1.us.above.net (64.125.31.182)  200.319 ms  200.241 
ms  200.104 ms
20  so-0-0-0.cr2.lga2.us.mfnx.net (208.184.232.198)  196.253 ms  198.288 
ms  196.325 ms
21  core1-lga2-oc48.lga4.above.net (64.124.232.2)  196.178 ms  196.862 
ms  196.239 ms
22  209.249.11.94.adelphiacom.net (209.249.11.94)  204.103 ms  196.565 
ms  198.199 ms
23  g1-01-00-00.r0.nyc90.adelphiacom.net (66.109.1.13)  201.656 ms  196.748 
ms  196.561 ms
24  p3-01-02-00.n0.nyc90.adelphiacom.net (66.109.0.181)  200.512 
ms  200.233 ms  200.267 ms
25  p3-00-01-00.n0.dca91.adelphiacom.net (66.109.0.78)  201.235 ms  201.17 
ms  201.883 ms
26  p3-00-01-00.n0.mia95.adelphiacom.net (66.109.0.38)  249.372 ms  245.608 
ms  248.069 ms
27  p3-00-00-00.r0.mia95.adelphiacom.net (66.109.0.194)  250.418 
ms  249.463 ms  244.708 ms
28  g1-00-00-00.a0.mia95.adelphiacom.net (66.109.1.222)  251.045 
ms  249.356 ms  250.872 ms
29  g1-00-00-00.ber01.miamfl.adelphia.net (66.109.14.226)  250.553 
ms  249.795 ms  249.494 ms
30  68.168.1.82 (68.168.1.82)  246.478 ms  252.337 ms  253.186 ms
************ this is 2 hops short of the target machine ******************

---

From: Neil Spring <[email-masked]>
Date: Sun, 7 Dec 2003 00:23:54 -0800

On Sat, Dec 06, 2003 at 11:52:21PM -0800, jon bennett wrote:

> I plugged my laptop into my uncle's cable modem and
> started tracing the path from various traceroute servers
> back to my machine.

I enjoy playing with traceroute too.  To see the paths
toward the IP address of that cable modem from the 80
planetlab sites scriptroute runs on, take a look at one of
the following:

http://www.scriptroute.org/treeserver/67.22.106.30.pdf [ 66 KB]
http://www.scriptroute.org/treeserver/67.22.106.30.eps [419 KB]

Of course, many planetlab sites are at well-connected US
universities, so this experiment settles few quarrels.
However, there are a couple servers around 30 hops away
(taiwan and canada), and several more than 20 hops away.
The two in the upper right corner of the rendering appear to
filter icmp or have a routing loop.

Don't worry; the tool avoids repeated traversals of a branch
of the tree, so your uncle's cable modem was unharmed.

-neil

---

From: jon bennett <[email-masked]>
Date: Sun, 07 Dec 2003 05:45:04 -0800

neil, first let me thank for the graphs and data, it was quite cool to get 
an independent measurement so fast from so many hosts.

>universities, so this experiment settles few quarrels.

I don't know, I think that it does, between the two of us we managed 
without much effort to show that there will be lots of paths (way more than 
0.5%) for which 45 records in a 576 byte packet will not get you both the 
forward and backward paths.

>of the tree, so your uncle's cable modem was unharmed.

thanks im sure he appreciates that :-)

jon

---

From: jon bennett <[email-masked]>
Date: Mon, 08 Dec 2003 21:14:41 -0800

I am replying to this on the list since this might be a problem for others 
as well

At 10:57 AM 12/8/2003 +0100, Maurizio Molina wrote:
>Jon,
>could you point where I can find your draft? from the only pointer I have 
>is this one, which you provided when you started the thread "the case of 
>an Internet Measurement Protocol" on the IMGR ML,
>but it doesn't work from my browser (Netscape)
>
><ftp://ftp.rutgers.edu/pub/internet-drafts/draft-bennett-ippm-ipmp-01.txt>ftp.rutgers.edu/pub/internet-drafts/draft-bennett-ippm-ipmp-01.txt
>Thanks,
>Maurizio

try this link for the latest draft

http://ftp.apnic.net/ietf/internet-drafts/draft-bennett-ippm-ipmp-01.txt

and this one for my original draft which has the redirection and error 
reporting sections which I took out of the 01 version in anticipation of 
moving them into their own separate drafts

http://ftp.apnic.net/ietf/internet-drafts/draft-bennett-ippm-ipmp-00.txt

jon

if those don't work let me know and I will just email you copies of them

---

From: jon bennett <[email-masked]>
Date: Tue, 09 Dec 2003 17:42:19 -0800

At 09:07 AM 12/5/2003 +1300, Matthew Luckie wrote:
>easy to implement" argument goes out the window,

so your claim is that deciding to leave the packet alone based on the 
result of an 8 bit comparison somehow makes the design so loosely 
constrained that it is no longer easy to implement? One 8 bit compare and 
the whole thing just "goes out the window"? This must be some kind of 
strange joke where you forgot to get to the punch line before you hit 'send'?

>and becomes non compliant with point 12 of RFC 1925

Non compliant with point 12 of RFC 1925???? ah now I see that's the punch 
line, now I know you are joking, I mean you couldn't really be insisting on 
compliance with an APRIL FOOLS DAY RFC could you?
(go take a good look at the RFC header again... )

Or could you? I suppose there is some small chance that you were not joking 
in which case I would suggest that you read the whole RFC and not just the 
part of it which you think (incorrectly) supports your point of view. 
Specifically I suggest that you read points 1, 4 and 10, those being

(1)  It Has To Work.

You may 'think' that only handling paths of 22 hops or less is 'ok', it isn't

(4)  Some things in life can never be fully appreciated nor
      understood unless experienced firsthand. Some things in
      networking can never be fully understood by someone who neither
      builds commercial networking equipment nor runs an operational
      network.

You may 'think' something is too hard to implement, others may 'know' that 
it isn't

(10) One size never fits all.

You may 'think' a protocol which addresses only your concerns is good 
enough for everyone else, it isn't

---

From: jon bennett <[email-masked]>
Date: Tue, 09 Dec 2003 23:22:33 -0800

>  a measurement
>request (if there is such an address)

I guess I will second Maurizio's question about this, could you explain 
what you meant here?

---

From: Tony McGregor <[email-masked]>
Date: Thu, 11 Dec 2003 06:58:07 +1300 (NZDT)

> be unable to return directly to the sending host.

The IMP proposals we have so far are echo protocols.  A break in the
forward path will mean there is no reply so in this case the same
problem does exist for a break in the forward path.

No reply may not be such a bad thing since that is what the network is
doing to data packets sent on that path.

Are you proposing a `break detection' functionality that notices that
there is a break and then generates a reply from the point of the
break?

----------------------------------------------------------------------------
Tony McGregor                   Mail:   [email-masked] 
Department of Computer Science  Phone:  +64 7 838 4651 
Waikato University              Fax:    +64 7 858 5095(w) +64 7 825 5047(h)
Private Bag 3105                Home:   +64 7 825 5040 mobile: (021)313004
Hamilton, New Zealand           www:    http://www.cs.waikato.ac.nz/~tonym
----------------------------------------------------------------------------

---

From: jon bennett <[email-masked]>
Date: Wed, 10 Dec 2003 16:45:30 -0800

>problem does exist for a break in the forward path.

this is not what I was talking about. I was saying "if you could have the 
router at the break send back a packet" would there be a problem. In the 
forward path case there would not be a problem, in the backwards path case 
there would be since even if you could get the router so send you back a 
packet, that packet would not be able to reach you.

That IMP is an echo protocol does not present a problem here, if you have 
probed the path before then you will know the addresses of routers on the 
path and (hopefully) be able to send them an Echo packet to which they will 
reply. In the backwards path case even if they are willing to reply you 
will not get their response.

I will address the case where you have not probed the path before later in 
this message.

>doing to data packets sent on that path.

I'm sorry you lost me there. When the network is broken is precisely when I 
want as detailed a reply as I can get so that I can possibly identify the 
source of my problem. This is when not being able to get a reply is the 
last thing I want, so I can't see at all how it might "not be such a bad 
thing".

>there is a break and then generates a reply from the point of the

I'm not really 'proposing' anything, I just want to be able to utilize 
existing network properties to their fullest. If you don't get a normal 
response to your IMP Echo packet, you can do an IMP 'traceroute' to find 
the identity of the last reachable hop. IMP of course can do a traceroute 
in 2* log N packets for an N hop path, by sending with TTLs of 
2,4,8,16,32... and when you over shoot you binary search for the last hop 
(or you can just binary search from 127 and do it in 8 packets for any 
length path). At which point you can send an Echo/Information packet to the 
last hop before the break.

Now for the case of the reverse path if the host was nice enough to notice 
that the time exceeded message contained the beginning of an IMP message 
which had been redirected through it, it could reverse the redirection and 
send you back an IMP packet with an error report which contained the source 
address from the ICMP packet. At which point you could send a redirected 
Echo to that router letting you see what the backward path is.

No in one of the earlier messages on this topic I said.

In a message on 11/13/03 Jon wrote
>  "To make this work really well it would be nice if we could specify that 
> the TTL=0 behavior of the router would be to send back the IMP packet as 
> if it had been turned around rather than sending back a time exceeded.

Now this would be the best approach (and it would be 'proposing' something) 
as it would make the life of the host, either the source in the forward 
path case, or the destination in the backward path case's life a lot easier 
as it would eliminate the need to search through time exceeded ICMP 
messages looking for IMP packets which it might want to process.

While different from the normal TTL=0 handling case for a router, it would 
likely be easier to do as it would not require the allocation of a new 
packet and the copying of the contents of the original packet into the ICMP 
packet. It also is not required to make the approach work, it just makes 
life a lot easier on the hosts, and makes the packet more likely to get 
back to you if it has to go through a NAT/firewall on its return.

---

From: jon bennett <[email-masked]>
Date: Wed, 10 Dec 2003 16:49:51 -0800

>except for the TTL field, which are set to whatever TTLs you're interested

Matt, I was going to reply to this but then I realized that I was not sure 
if you were giving this as an example of a practical method of performing 
this function. Or if you were just giving it as an example of an approach 
which you would also consider to not be "tightly constrained and easy to 
implement".

---

From: jon bennett <[email-masked]>
Date: Thu, 11 Dec 2003 17:20:33 -0800

Maurizio,

when discussing measuring a sampling of routers you said

>  or using a very few bits (an IPMP can write a paket only if the TLL ends 
> with the same bit pattern).

to do this you would need two things, you would need a mask of the bit 
pattern, and a mask (or a count which would wind up being used by the 
router to make a mask) of which bits out of the 8 in the TTL you wanted to 
match against the pattern.

in the interests of simplicity, would it suffice to have the packet be 
stamped only if the TTL was some even multiple of 2? In other words there 
would be for example the IMP packet would have a 3 bit field (N) and only 
if the last N bits of the TTL were 1 (or 0?) would the packet be stamped. 
this would let you test every 2nd, 4th, 8th, 16th, etc router. By altering 
the initial TTL value you would be able to change where the series started. 
for example if you had set N to 2 then a packet sent with TTL=255 would measure

TTL                     stamp   router
255=11111111            NO      1
254=11111110            NO      2
253=11111101            NO      3
252=11111100            YES     4
251=11111011            NO      5
250=11111010            NO      6
249=11111001            NO      7
248=11111000            YES     8
etc
yielding stamps by routers
4,8,12,16,20,etc

but if instead you sent it with a TTL=253 you would get

TTL                     stamp   router
253=11111101            NO      1
252=11111100            YES     2
251=11111011            NO      3
250=11111010            NO      4
249=11111001            NO      5
248=11111000            YES     6
247=11110111            NO      7
246=11110110            NO      8
etc
yielding stamps by routers
2,6,10,14,18,etc

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 Dec 2003 23:05:01 -0500

Jon (and all)-

> You may 'think' something is too hard to implement, others may 'know'
> that it isn't
> 
> 

The above sort of email is not condusive to moving forward technically
on a measurement protocol.  I'd ask that you (& everyone) make an effort
to keep the discussion technical in nature and drop the insults.  This
is getting us nowhere good.

Thanks!

allman
(wearing imrg chair hat)

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: jon bennett <[email-masked]>
Date: Fri, 12 Dec 2003 00:06:34 -0800

>'d ask that you (& everyone) make an effort
>to keep the discussion technical in nature and drop the insults.

Sorry about that, I sometimes forget that my idea of biting sarcastic humor 
sometimes comes across as more bite and less humor than was intended. I 
will strive to keep it dry and technical in the future.

jon

---

From: Maurizio Molina <[email-masked]>
Date: Fri, 12 Dec 2003 18:06:12 +0100

Hi Jon,
the scheme you propose is probably the one that gives the maximum 
flexibility with the minimum number of bits in the header (3).
However, in case you're intrested in measuring what happens on a set of 
X routers close to each other (i.e. on a sequence of next hops), AND 
these routers are far from the source (or on the reverse path) AND  you 
have a IPMP packet constrained in size,  you may have (in the worse 
case) to use X packets to let  each of these X routers fill the packet 
(playing with the TTL as you showed). Beyond having to spend X packets, 
 you'll never be able to have in the same packet the timestamps of all 
these X neighbouring routers, which may be a limitation.
An example (numbers are only for the sake of clarifying what I mean): 
suppose your IPMP pkt can only contain 10 records and you're interested 
in measuring  
routers at "position" 21,22,23 along the path. Even if 3 path records 
would all fit in one IPMP message, with your mechanism you cannot 
specify N=0 (measure each hop),  Neither  N=1 (measure each two hops) as 
 places for path records would be exhausted at router  10  (N=0) or at 
router 19 or 20 (N=1, depending if you set the initial TTL even or odd). 
To "reach" hop 21 you have to set N=2 (measure each 4 hops), but then no 
matters how to play with the TTL you'll only have simultaneously, into 
the IPMP pkt, only one of the records you're interested in.
To  select a range of routers I see no other way than spending 2 bytes 
(16 bits) in the header, with an explicit start and end index.
With 19 bits (start and end index + the 3 bits you suggested) we have 
probably all the flexibility we need.
I'm not pushing right now for one schema or the other, just wanted to 
point out that nothing comes for free...
Maurizio 

jon bennett wrote:

>>  or using a very few bits (an IPMP can write a paket only if the TLL 
>> ends with the same bit pattern).
>
>
> router to make a mask) of which bits out of the 8 in the TTL you 
> wanted to match against the pattern.
>
> stamped only if the TTL was some even multiple of 2? In other words 
> there would be for example the IMP packet would have a 3 bit field (N) 
> and only if the last N bits of the TTL were 1 (or 0?) would the packet 
> be stamped. this would let you test every 2nd, 4th, 8th, 16th, etc 
> router. By altering the initial TTL value you would be able to change 
> where the series started. for example if you had set N to 2 then a 
> packet sent with TTL=255 would measure
>
> TTL                     stamp   router
> 255=11111111            NO      1
> 254=11111110            NO      2
> 253=11111101            NO      3
> 252=11111100            YES     4
> 251=11111011            NO      5
> 250=11111010            NO      6
> 249=11111001            NO      7
> 248=11111000            YES     8
> etc

---

From: jon bennett <[email-masked]>
Date: Fri, 12 Dec 2003 18:17:55 -0800

Maurizio,

>flexibility with the minimum number of bits in the header (3).

The number of bits in the header is not a big deal at this stage. What I 
was first trying to do was better understand what were the problems you 
wanted to solve, and then once it is clear what the problems are it is 
easier to look at possible ways to solve those problems. As I understand it 
you have two separate concerns. The first is to monitor the whole path 
without having to monitor every single router on the path. It sounds like 
you think the 'every (2^N)'th router' approach addresses that concern.

Then you have a second problem to solve which I think is unrelated to the 
first one. (Is that a safe assumption? Or is there any chance they are 
related, and that you would need to do both at once?)

>However, in case you're intrested in measuring what happens on a set of X 
>routers close to each other (i.e. on a sequence of next hops), AND these 
>routers are far from the source (or on the reverse path) AND  you have a 
>IPMP packet constrained in size,  you may have (in the worse case) to use 
>X packets to let  each of these X routers fill the packet (playing with 
>the TTL as you showed). Beyond having to spend X packets, you'll never be 
>able to have in the same packet the timestamps of all these X neighbouring 
>routers, which may be a limitation.
>suppose your IPMP pkt can only contain 10 records and you're interested in 
>measuring
>routers at "position" 21,22,23 along the path.

In my draft one of the IMP header fields is called "Start TTL", and its use 
is to delay the insertion of path records as long as the TTL value is 
greater than the Start TTL value, so if you wanted to measure routers 
21,22,23 you could set the Start TTL to 235, and you would then only get 
records from 21,22,23,  plus however many more records fit in the remainder 
of the packet. Does it matter if you have records inserted after the 
routers you are interested in? If it doesn't matter then you would not need 
to have a Stop TTL, just the Start TTL. Now if you really don't want any 
more records in the measurement that could be done without needed any more 
header fields. You could set the value of the "Path Pointer" to be "Packet 
Length" - "Size of 3 Path Records" so that the packet filled up after you 
got the three records you wanted.

>point out that nothing comes for free...

Now if it was acceptable to do the trick with setting the Path Pointer so 
that the packet filled up then you would only need 11 bits, 3 for the 
2^N'th skipping and 8 for the Start TTL. The reason I asked before about 
would you need to do both of these at once is that if you didn't then you 
could reuse the Start TTL bits when you wanted to do the 2^N'th skipping 
and then only need 9 bits (8 for the Start TTL and 1 bit to tell you which 
function it was implementing). The other benefit of reusing the Start TTL 
field for this purpose would be that instead of making the router make a 
mask from 3 bits you could just make the sending host put the mask in the 
Start TTL field (which would have to be renamed something like TTL Select, 
having more than one use now), that way the router could just AND the TTL 
Select field with the TTL rather then having to generate a mask first and 
then AND it.

I think skipping to every 2^N'th hop would be quite useful, particularly 
for size constrained packets like VoIP where recording every 4'th router 
would let you monitor a path up to 40 hops long with a single packet (In my 
draft there is a flag in the header which lets you collect path records 
only on the forward or backward path so you could use all 10 of the records 
in a G.711 VoIP packet for one direction).

So I think both mechanisms have there uses, my question would be do you 
need to be able to use both at once? or is it ok to only be able to use one 
of them at a time?

---

From: Maurizio Molina <[email-masked]>
Date: Mon, 15 Dec 2003 15:28:31 +0100

jon bennett wrote:

> The number of bits in the header is not a big deal at this stage. What 
> I was first trying to do was better understand what were the problems 
> you wanted to solve, and then once it is clear what the problems are 
> it is easier to look at possible ways to solve those problems. As I 
> understand it you have two separate concerns. The first is to monitor 
> the whole path without having to monitor every single router on the 
> path. It sounds like you think the 'every (2^N)'th router' approach 
> addresses that concern.
>
> Then you have a second problem to solve which I think is unrelated to 
> the first one. (Is that a safe assumption? Or is there any chance they 
> are related, and that you would need to do both at once?) 

Jon,
For the use cases I can think about now, I'd say that the problems are 
rather separated, and being able to use the two schemes together is more 
a "nice to have" than a strong requirement. Therefore, if there's an 
argument for NOT using them together in favour of  bit saving and 
implementation simplicity (as you explain in the following) I think it 
should be seconded.

>
>
>> However, in case you're intrested in measuring what happens on a set 
>> of X routers close to each other (i.e. on a sequence of next hops), 
>> AND these routers are far from the source (or on the reverse path) 
>> AND  you have a IPMP packet constrained in size,  you may have (in 
>> the worse case) to use X packets to let  each of these X routers fill 
>> the packet (playing with the TTL as you showed). Beyond having to 
>> spend X packets, you'll never be able to have in the same packet the 
>> timestamps of all these X neighbouring routers, which may be a 
>> limitation.
>> suppose your IPMP pkt can only contain 10 records and you're 
>> interested in measuring
> In my draft one of the IMP header fields is called "Start TTL", and 
> its use is to delay the insertion of path records as long as the TTL 
> value is greater than the Start TTL value, so if you wanted to measure 
> routers 21,22,23 you could set the Start TTL to 235, and you would 
> then only get records from 21,22,23,  plus however many more records 
> fit in the remainder of the packet. Does it matter if you have records 
> inserted after the routers you are interested in? If it doesn't matter 
> then you would not need to have a Stop TTL, just the Start TTL.

I also agree that it's not necessary to have a "TTL end" field in the 
header, as it only brings marginal advantages.

> Now if you really don't want any more records in the measurement that 
> could be done without needed any more header fields. You could set the 
> value of the "Path Pointer" to be "Packet Length" - "Size of 3 Path 
> Records" so that the packet filled up after you got the three records 
> you wanted.
>
> Now if it was acceptable to do the trick with setting the Path Pointer 
> so that the packet filled up then you would only need 11 bits, 3 for 
> the 2^N'th skipping and 8 for the Start TTL. The reason I asked before 
> about would you need to do both of these at once is that if you didn't 
> then you could reuse the Start TTL bits when you wanted to do the 
> 2^N'th skipping and then only need 9 bits (8 for the Start TTL and 1 
> bit to tell you which function it was implementing). The other benefit 
> of reusing the Start TTL field for this purpose would be that instead 
> of making the router make a mask from 3 bits you could just make the 
> sending host put the mask in the Start TTL field (which would have to 
> be renamed something like TTL Select, having more than one use now), 
> that way the router could just AND the TTL Select field with the TTL 
> rather then having to generate a mask first and then AND it. 

Just a clarification. Are you thinking of a generic mask or of a mask 
which always ends with a ones' string? (i.e. 00000001, 00000011, etc...)?
My point is that even if we could have a generic mask, I don't think 
it's useful. With a generic mask with X bits set to 1, the number of 
 TTL values that are matched is equal to the number of  TTL values that 
are matched with the mask ending with X ones, but we "loose" the 
property that these matched TTL are equally spaced.
Example: (Immagine the TTL  is on four bit only, for simplicity)
- the mask 0011 would match with TTL = 3,7,11,15 (4 TTLs, equally spaced 
of 4)
- the mask 0101 would match with TTL 5,7,13,15 (always 4 TTLs, but not 
equally spaced)

>
>
> I think skipping to every 2^N'th hop would be quite useful, 
> particularly for size constrained packets like VoIP where recording 
> every 4'th router would let you monitor a path up to 40 hops long with 
> a single packet (In my draft there is a flag in the header which lets 
> you collect path records only on the forward or backward path so you 
> could use all 10 of the records in a G.711 VoIP packet for one 
> direction).
>
> So I think both mechanisms have there uses, my question would be do 
> you need to be able to use both at once? or is it ok to only be able 
> to use one of them at a time? 

See above, I think it's ok to use one of them at a time
Maurizio

---

From: jon bennett <[email-masked]>
Date: Mon, 15 Dec 2003 14:33:10 -0800

Maurizio,

>rather separated, and being able to use the two schemes together is more a 
>"nice to have" than a strong requirement. Therefore, if there's an 

The argument for not doing them together is just that if its not really 
needed there is no point in making software implementation perform both 
tests. And by only having one or the other, we can use the explicit mask 
rather then decoding 3 bits, which makes the implementation easier without 
needing any additional bits.

>>If it doesn't matter then you would not need to have a Stop TTL, just the 
>>Start TTL.
>

ok

>My point is that even if we could have a generic mask, I don't think it's 
>useful. With a generic mask with X bits set to 1, the number of TTL values 
>that are matched is equal to the number of  TTL values that are matched 
>with the mask ending with X ones, but we "loose" the property that these 
>matched TTL are equally spaced.
>- the mask 0011 would match with TTL = 3,7,11,15 (4 TTLs, equally spaced of 4)

The answer to your question is, 'yes' :-)

What I would envision is a mask which SHOULD be set to end with a string of 
ones, 0..01, 0..011, 0..0111, etc, but that it would be the responsibility 
of the sender to set them properly. The behavior of the device in the case 
of the 0101 mask might not even be defined. So it would be a 'generic' mask 
but only when the mask was set to one of these values
00000000
00000001
00000011
....
01111111
11111111
would the behavior of the device marking the packet be specified.

To require the mask to end with 1's would force devices to check it and 
then do something when it wasn't, and if the sender doesn't set the bits 
right they only cause trouble for themselves so it doesn't seem to be worth 
requiring it.