Subject: [MBONED] Some questions and suggestions on ssmping draft

From: Bharat Joshi <[email-masked]>
Date: Wed, 18 Jul 2007 20:47:47 +0530

Hi Stig,

      I have some questions and suggestions on ssmping draft:

* I think following statements can be reworded in introduction:

"whether it is able to receive a multicast flow" to "whether it can receive a multicast flow"

"Additionally it is able to report other information such as the amount of time used to establish the multicast tree, the number of hops the flow's packets have traveled as well as the packet delay and loss. "

to

Additionally it can also report following informations:
* The amount of time used to establish the multicast distribution tree.
* The number of hops the unicast and multicast packets travels.
* The packet delay and packet losses.

* In 'Architecture', please reword the following sentences:

"knowing one of the server's unicast addresses is required"

to

"Server's unicast address must be known out of band" or something similar.

"After joining the channel, the client sends ssmping requests encapsulated in UDP to the standardised ssmping port and the unicast address of the server."

to

"After joining the channel, the client unicasts the ssmping request to the server. The request is encapsulated in UDP with destination port set to the standardised ssmping port."

* Can ssmping also be used to find out if the multicast and unicast topology differs? One way I can think of is using 'hop' counts but this would not be a concrete method. Can we possibly mention a request option which can force server to use 'record route' option in the unicast and multicast message it generates? I think this way when a client receives the message, it can compare whether they both took the same path or not.

* Please reword the following sentence as it is not clear:

" One as unicast back to the port and address the request was sourced from, and also as multicast back to the port the request came from. "

to

" One reply that is unicast to the address, this request was sourced from. Another reply as multicast back to the port the request came from."

or something similar

* The following sentence can be more simple:

"Hence provided that the client receives unicast replies, a failure in receiving multicast indicates either a multicast problem or a multicast administrative restriction. "

to

"There could be either a multicast problem or a multicast administrative restriction if a client receives unicast replies but does not receive multicast replies"

* Under protocol specifications:

"The protocol here defined does not require the use of any options, and a client may operate without specifying any."

to

"The protocol defined in this document does not require to use any options and a client may operate without specifying any options".

* Under defined options, in 'Multicast group' type 4: we mention that this is currently used by a tool 'asmping'. I had an impression that 'asmping' is part of 'ssmping' as mentioned in the introduction. So can you please fix this with proper explanation?

* For Type 7, Reserved, its mentioned that Server should ignore this. Does it means that it should not echo it back in the reply?

* For Type 8, Pad, if the reply size is less than the request size, shall it add more padding? This function mention that server should try to create the reply size same as the request size.

* How does client comes to know about the group? Does ssmping client asks the ssmping server about this? Does type 4 'multicast address' is used for ssmping also?

* Can a client use any multicast group address in the SSM range or admin scoped multicast address configured to be used for SSM?

* Does the unicast payload and multicast payload is same in the replies? I mean it contains the same options echoed back by the server.

* Can we create an option asking for replies to be of a given size? This will help in debugging problems associated with fragmentation of multicast packets.

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

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

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Jul 2007 11:17:06 +0200

>       I have some questions and suggestions on ssmping draft:

Thanks for the detailed review. I agree with most of your suggestions
for textual changes. I've removed those and will try to answer the
others.

[...]
> * Can ssmping also be used to find out if the multicast and unicast topology differs? One way I can think of is using 'hop' counts but this would not be a concrete method. Can we possibly mention a…

Yes, this isn't pointed out in the draft, but that is partly why I want
to have both unicast and multicast replies. The hop count would be a
clear indication (at least for SSM. Partly for ASM where the hop count
might also help show whether forwarding is via registers/MSDP, RPT or
SPT). The delay might also give some indication I guess.

[...]

> * For Type 7, Reserved, its mentioned that Server should ignore this. Does it means that it should not echo it back in the reply?

Option 7 was used (or is used in many deployments of the draft 00
protocol) for specifying reply size, see my comment below. At least
as long as the protocol is backwards compatible I think it's best to
not re-use the option value. By ignore I mean that the server should
not do any processing, but should as always (only exception is the pad
option below) echo the client options back unchanged.
> * For Type 8, Pad, if the reply size is less than the request size, shall it add more padding? This function mention that server should try to create the reply size same as the request size.

Since all client options (except for the pad option) are echoed back
unmodified, it will never need to add more padding to make reply size >=
request size. The idea is basically that if you want to test that you
can receive multicast packets at say 1500 bytes, the user can specify
that size 1500 is desired. The client can then take the request (which
should be much smaller) and add padding to make the request 1500. As
long as any options the client might add fits inside the additional
padding (with say 1500 this is no problem), the responses will be
exactly 1500. If the client adds no padding (or too little padding),
the responses will be a bit larger (possibly a bit larger than the
user hoped for). This replaces the previous option 7, see below for
the reasoning.

> * How does client comes to know about the group? Does ssmping client asks the ssmping server about this? Does type 4 'multicast address' is used for ssmping also?

Currently for ssmping there is a fixed adress and the multicast address
option is not used (perhaps it should be). For asmping the option is
currently always used. There are several cases (like admin scoping and
embedded-RP) where it is quite useful to specify the address.

There are a couple of issues with this. For ssmping you will see all
replies the server sends to other clients. For asmping, the ability to
pick the group might be abused to make the server send data to a group
that is used by some other application/service.

It has been suggested that the server could instead have a pool of
groups where a client would send an initial request, getting a unicast
response back with a group address, and then use that for the pings.
This might be a good way to do things, however it is still quite useful
for a user to specify say the scope or initial bits of the group
address. I suppose the server could have multiple pools where it gives
the client a group inside a prefix suggested by the client if possible.
As a special case the client could also specify a one-group prefix.
The server administrator could choose which pools should be available.

If the server can not give the client a group inside the prefix it
wants (perhaps server has exhausted its pool of groups), or if the
server is too heavily loaded or whatever, it could give a unicast
response saying that. Then the client would never try initiate the
ping sequence.

This is not in rev 01. I'll talk about this in my presentation and see
what you and others think.
> * Can a client use any multicast group address in the SSM range or admin scoped multicast address configured to be used for SSM?

So currently for SSM the group is fixed. For ASM there is nothing
stopping the user from trying to use an SSM group. I could certainly
make it so that you can pick the SSM group if you think that is useful.
But all this will be quite different anyway if we choose to let the
server pick the group (possibly with hints from the client).
> * Does the unicast payload and multicast payload is same in the replies? I mean it contains the same options echoed back by the server.

Yes, usually, maybe I should point that out. The server echoes back
what it got from the client (except client pad might be adjusted) and
may add some options on its own. Currently the only thing that might
differ, is the timestamp. If the server is asked to do timestamps,
then it will try to use the time when the message is actually sent
(which might be difficult to get accurate), and of course this will
be different for the two messages. Depending on what new server
options might be defined. For debugging it could perhaps be useful in
some cases to make sure they are exactly the same. At least currently
the size will be the same, and unless the client asks for server
timestamps they will be exactly the same. Well, at least the IP header
will be different anyway.
> * Can we create an option asking for replies to be of a given size? This will help in debugging problems associated with fragmentation of multicast packets.

This brings me back to option 7 and 8 discussed above. I think this is
useful and is why I added option 7. However, as it has been pointed out,
it can be abused. You can send small requests and ask for a reply size
of say 65535. You might then send one single request and get more than
40 packets sent to where you like (say by forging your unicast source
address). With the new option 8 I am trying to achieve the same (the
client can choose the reply size), but the reply will never be much
larger than the request. Unless we add too many server options the
client can ask to get in the same response.

I hope this clarifies things. It seems clear some more text is needed
in the draft. I hope at the meeting to discuss major architectual things
like whether the server should allocate the group (I have a couple of
other things to discuss as well). Once those things are settled I will
try to improve the overall quality of the draft.

Thanks for the good review Bharat,

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Jul 2007 11:17:06 +0200

[...]

[...]

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 19 Jul 2007 16:54:15 +0530

Hi Stig,

> for textual changes. I've removed those and will try to answer the

Thanks. Please see my response in line.

Regards,
Bharat

> SPT). The delay might also give some indication I guess.

Thats right. Delay and hop-count may give you some indications but this
may not trusted and thats why I suggested 'record route' option. The
only thing I am not sure is if all the routers in a network would be
configured to support this.

As I mentioned, this will be very helpful when unicast and multicast
topologies are not same and also you can analyze the delay and hop count
values with this information.

> option below) echo the client options back unchanged.

Ok.

> user hoped for). This replaces the previous option 7, see below for

Ok.

> embedded-RP) where it is quite useful to specify the address.

Ok. So the group address is hard coded in the ssmping client. Right?

Yes. I think it would be really good if we provide an option to pass the
group address. In any case, we pass another option to tell whether we
want to do a ssmping or asmping so this can be used to differentiate
whether we want to do ssmping or asmping.

> that is used by some other application/service.

But ssmping or asmping will be sending that data to a standardize UDP
port and also the data rate is very very low so I think this should be
ok. Also it looks to me that if we provide a two way handshake between
ssmping client and ssmping server to just authenticate each other, all
these problems can be removed.

Why I suggested the authentication part is just because these tools will
always be used by a network administrator and he would always know the
key/password etc to get authenticated.

> The server administrator could choose which pools should be available.

Yes. I also mentioned that. Client can ask a server what all multicast
groups it can server and than start the testing for each one of those
group and report the results.

Actually it would be ideal if we can keep the ssmping server serves
those groups whose sources are very close to him. But this may not
always be possible.

We can also use a DNS kind of environment here so as and when ssmping
client is executed, it is passed the IP address and a multicast address.
It sends a ssmping server query to this IP address and get a list of IP
addresses of ssmping server. It than generates the ssmping requests to
one server or may be to all servers.

I also liked the method you have mentioned in your reply.

> what you and others think.

Ok. Could you please send me the presentation offline? I would not be
there in Chicago.

> server pick the group (possibly with hints from the client).

Yes. I think ssmping should allow either 232/8 and 239/8 for SSM range.
An admin scoped domain may use 239/8 as SSM range.

> will be different anyway.

Yeah. It would be good if we can explicitly say this. I would also
suggest to add some text on what all information can be used from these
payloads to deduce certain facts. Something like delay in unicast
topology and comparison of this with delay in multicast topology. Losses
in both of them. Hop count in both of them.

> client can ask to get in the same response.

Ok. Yes. Actually with this we really do not fix the problem you were
pointing out. A user can still create the same issue by sending a big
request. The only thing is now instead of (40 + 1) packets, there will
be ( 40 + 40 ) packets.

> try to improve the overall quality of the draft.

Yes. Though I had understood things but a clarification was required to
confirm them.

I was thinking a little more about it and have couple of more questions
and suggestions:

* We can add another option in ssmping client. This option will take
starting size and a delta size. ssmping client can increase the size of
the next request by this delta. For example, ssmping client starts with
100 bytes payload and delta is 50. Next request it sends is of 150
bytes, next is of 200 , 250 and so on.. This may be helpful in finding
out the threshold size till everything is fine.

* We should have an option of getting the list of multicast groups
addresses from ssmping server and using one or all of them when user
does not want to use any specific group address to be used. We discussed
this in one of my comments.

* Lets assume that ssmping client sends a request to ssmping server, is
there a way that ssmping server can tell ssmping client that it does not
serve a given multicast group. Maybe we can use ICMP messages here.

* I did not find any mention of how and when ssmping stops sending
requests. Is it that the request is sent only once?

* It would be good if we can reserve a standardize UDP port for ssmping.

Actually I had been thinking about the requirements of an ideal
multicast debugging tool but later realize that there could be nothing
like that. You would need to use different tools that suits your
requirement. I must admit that ssmping is pretty simple in functioning
and pretty useful too.

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 19 Jul 2007 16:54:15 +0530

Hi Stig,

Regards,
Bharat

Ok.

Ok.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Jul 2007 13:58:12 +0200

> values with this information.

I agree. I forgot to comment on that. It would certainly be interesting.
I'm not sure whether it is supported that much either. I'll look into
it.

[...]

> Ok. So the group address is hard coded in the ssmping client. Right?

Right
> whether we want to do ssmping or asmping.

Note that the server doesn't really need to care about ssmping or
asmping. It only matters which group. This is simple if the client
specifies a group (or perhaps a prefix).
> port and also the data rate is very very low so I think this should be

One of the things I will bring up, is whether there should be a standard
client port. It helps security to have a fixed ports for clients to
listen to, but it means you cannot run multiple clients on the same
host (AFAIK).

> key/password etc to get authenticated.

Right, we could do some optional authentication. If we do a query/reply
for obtaining the group address before starting pinging, we could
certainly do authentication as part of that as well.

> group and report the results.

I don't see the value in having the client try a large range of groups.
I would rather have client tell the client, I want to test a group in
my admin scope, say 239.255/16 (or whatever), the server then picks a
group inside that range (if server is configured to do so) and tells
the client which group it should use. Apart from scoping and being able
to choose groups mapping to different RPs, the client shouldn't need to
pick the group I think.

It requires some thinking to find a sufficiently simple mechanism that
does just what we need for this.
> one server or may be to all servers.

I have been thinking a bit about how one could locate ssmping servers.
Within an organisation, the simplest is definitely to just add several
A/AAAA records to some name and just leave the ordering to DNS. The
application would (at least my implementation) just pick the first A or
AAAA it finds (which of those comes first depends on the stack and
getaddrinfo()). However it would be possible for the client to try to
next in case of error.
> Ok. Could you please send me the presentation offline? I would not be

Oh ok. I need to start writing it I guess :)

> request. The only thing is now instead of (40 + 1) packets, there will

Well yes, but you have to send the 40 packets yourself. Only one host 
gets the 40 unicast reply packets, and you only get the multicast ones
if you are part of the multicast group.
> out the threshold size till everything is fine.

Yes, this however can be done by a client implementation without any
change in the protocol. E.g. the client can choose different size of
the pad option for each request.
> this in one of my comments.

Using all worries me. We may need to get a list as you say. The question
is how much control does the client need to have.
> serve a given multicast group. Maybe we can use ICMP messages here.

ICMP should only be used for transport failure I think. If we go for
an initial handshake to agree on groups, then I think the client just
sends an initial message with same format as now (including possibly
a wish for a particular group or group prefix), the server responds
back with the group to use or an error message.
> requests. Is it that the request is sent only once?

The client simply sends as many pings as it likes, pretty much like
the usual ping tool (ICMP echo). Unless we do some authentication the
server should do rate limiting and not respond to every request if
they arrive too quickly.
> * It would be good if we can reserve a standardize UDP port for ssmping.

Yes, at least on the server side.
> requirement. I must admit that ssmping is pretty simple in functioning

Thanks. I believe so myself. The difficult part now is that to make it
flexible and secure for Internet wide usage while remaining simple.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Jul 2007 13:58:12 +0200

[...]

Right

Stig