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