ASF vs. Intel AMT part 2 - Technology differences

By Shmuel Gershon (Intel) (8 posts) on September 10, 2007 at 6:51 am

Hi :)
(Please refer to the "part 1" post of this series, in order to learn the evolution line of manageability solutions and the origins of Intel AMT).

In the previous part, we talked about the (summarized) history of manageability. Now we will actually start comparing ASF and Intel AMT.

It is somewhat hard to compare Intel AMT and ASF in the technology layer.
Both are solutions to the same problem, but on the other hand Intel AMT has a lot more features than ASF, and you cannot compare the technology layer of a function when it does not even exists in ASF.
So, let's take a look at the features they have in common, and examine them with care from a solution developer point of view:

Part Two: Technology Differences

  1. Transport layer protocol: UDP vs. TCP
    • We are starting from the 'low level' networking protocols.
      This may be old news to some, but it may be new for other. And I am aware that some may claim this to be irrelevant. But the point is that ASF specification is built over UDP protocols, while Intel AMT uses TCP for most of his connections -- this has important implications on us, solution developers.
    • This can be significant when building a console to manage computers. If using UDP, the console developer needs to worry about reception and order, as UDP is unreliable and not-ordered. With TCP, the console sends the message once, and the underlying protocol cares of reception and order.
    • During my tests with ASF, it was usual to see remote consoles from different vendors sending the same packet more than once, trying to be sure the packet will get there. Sure, the ASF products have this 'acknowledgement' packet sent that assures the console the command came in correctly. But this 'acknowledgments' can be lost all the same (they're UDP), and if you had to 'acknowledge acknowledgements', the protocol would become infinite.
    • When you are sending a command over SOAP, or over WS-Man, you don't care (that much) about network hazards. It is a reliable protocol, in which the implicit TCP stack will re-transmit the command if it came lacking or was lost.
  2. Remote control protocol: RMCP vs. SOAP/WS-Man
    • RMCP is the "Remote Management and Control Protocol" used to send remote control (namely power down, power up and reset) to a client being managed. Apart from the fact that RMCP is a UDP-based protocol (see point 1), a clear disadvantage of the protocol is that it is entirely new and specialized.
    • Communications technology has evolved, and Web Services were invented as an all-around technique designed to support "interoperable Machine to Machine interaction over a network". If you are communicting between computers remotely, it is likely that you are dong it over Web Services.
    • In order to build an application that connects using SOAP, you don't need to iplement an obscure new protocol such as RMCP (or the more complex RSP), you just use popular Web Service libraries with SOAP or WS-Man.
  3. Remote booting: PXE vs. IDE-R
    • The two technologies above are meant to reboot a specific machine to boot from a remote disk.
    • Arvind defines PXE: "provides a basic network mechanism for BIOS to discover a PXE server on the network which can then be used to get additional information about image to download." But PXE is old (almost a decade), is not secure, reliable or even routable over different subnets.
    • IDE-R (IDE Redirection), on the other hand, can be secured (with TLS, for example), works on complex corporate network and subnets, and escalates well.
    • You can read Arvind's discussion on the drawbacks of PXE, and Ylian's thorough technology comparison. Also, there's an interesting comparison by Altiris of the two technologies here (notice how many workarounds they had to add to their management console software in order to keep PXE viable...).
    • Note 1: The miraculous surviving of PXE technologies for over 10 years is a distinct proof of the market interest/need in this feature. Hopefully Intel AMT's IDE-R can answer this need in a better way.
    • Note 2: If you still want to use PXE, in order not to throw away that PXE Boot Server ;), Intel vPro still offers PXE capabilities* (*depends on vendor BIOS implementation).

Stay with us for the next parts...

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

PS> It would be great to know whether some of you already had/have any experience with ASF manageability, and how do you compare it with Intel AMT. In this way, we'll be able to better focus our conversation.

Categories: Manageability, Software Engineering

Comments (12) Comments RSS Feed

By Arvind Kumar on September 12th, 2007 at 9:32 am
Shmuel, Good analysis!
I would just like to point out that IDE-R doesn't necessarily replace the need for PXE.
IDE-R is more for break-fix model, load a diagnostic OS and fix things. IDE-R is not necessarily suited for fast provisioning of OS and Applications on the systems. I believe that a combination of IDE-R (or Media Redirection in general) and host based (BIOS/EFI, better PXE) is still going to be the need from market.

By Shmuel Gershon on September 15th, 2007 at 10:44 am
Yes, Arvind - you are right.
That's why the "Note 2" is so important. For places where PXE are still needed, Intel vPro still has it available*. By having both options, managers can choose the best solution every time.

(*depends on vendor BIOS implementation)

By Patrick Kutch on September 19th, 2007 at 11:31 am
Shmuel, interesting comparisons, though they do not seem to be without some bias. To say that RMCP is "entirely new and specialized." does not seem very accurate, especially as you correctly pointed out in part 1 that it is an industry DMFT standard.

Another point is that while ASF is build on UDP, which in turn does have some gotchas that developers need to be aware of (such as retries), it is significantly of lighter weight than a WS-Man solution - a light-weight solution still has appeal to some customers.

I believe that while the WS-Man interface and Intel AMT are great technologies, there is still a need for ASF for certain customer segments and that ASF should not be dismissed so quickly.

I look forward for your future aritcles.

By Shmuel Gershon on September 19th, 2007 at 11:47 am
Patrick;
Even though I tried to be unbiased, it is hard to hide personal feelings when writing :)
Still I hope the posts are considerably objective and can be used as reference on the differences between the solutions.
Your point about the still existent need of ASF is correct too. Many segments use ASF and will continue to do so for a long time. That is exactly why the Intel vPro platforms offer ASF AND Intel AMT as manageability solutions (the customer can choose either Intel AMT or ASF). I will add a note about this in a next post.
Thanks for the attentive remarks!

By Intel® Software Network Blogs » Blog Archive » More technology distinctions - Intel AMT vs. ASF, part 3 on September 20th, 2007 at 8:02 am
[...] (Please refer to the "part 1" and "part 2" posts of this series, in order to learn the evolution line of manageability solutions and [...]

By Intel® Software Network Blogs » Blog Archive » ASF and Intel AMT - Spot the differences (part 1) on October 18th, 2007 at 8:05 am
[...] in the series: - ASF and Intel AMT - Spot the differences (part 1) - ASF vs. Intel AMT part 2 - Technology differences - More technology distinctions - Intel AMT vs. ASF, part 3 - Between Intel AMT and ASF, part [...]

By Intel® Software Network Blogs » Blog Archive » Between Intel AMT and ASF, part 4 on October 23rd, 2007 at 3:51 pm
[...] the previous three posts of this series (1, 2, 3), we talked about differences between the manageability two solutions, covering from the kind of [...]

By Блоги Intel® Software Network » Top 5 ISN Blogs в январе on January 29th, 2008 at 1:39 pm
[...] анализом технологий Intel AMT и ASF. В предыдущих частях (1, 2, 3, 4), Шмюэль рассказал об исторических аспектах [...]

By Johan on April 15th, 2008 at 6:41 am
To say that UDP is "less" reliable than TCP is not entirely correct. TCP itself transmits data in fragments over Ethernet, which have to be "acknowledged". It is just hidden from the software developer (In other words it takes the developer longer to get his client-server network layer working well). And finally remember that TCP can not multicast.
A feature request for IDE-R: How can we get a big ISO downloaded to 1000 client stations simultaneously to image them. I.e. this is a typical situation where you simply want to throw 1 image to 1000 devices as soon as possible. As far as I know this problem is today only solvable with PXE.

Thanks for the post - I love getting into the details as you can see! Regards - Johan.

By Johan on April 15th, 2008 at 6:58 am
Wouldn't you say PXE still trumps IDE-R when it comes to multicast imaging? For example, TCP brings a drawback when there's a need for multi-casting huge files to thousands of recipients in a manufacturing lab.

Finally: I would like to note that a "TCP" is "UDP with management". If you would run a network sniffer to compare the same solution developed on UDP, but switch-able to TCP by design - you would notice just about the same amount of packet loss between the two at packet level. And you would see just about the same amount of data throughput when you compare them. The trick is that with the UDP solution the developer has to manually handle packet loss and retransmissions. It is safer to use a tried and tested "management" library to do that for you.

By Shmuel Gershon on April 15th, 2008 at 8:47 am
Thanks for your inputs, Johan!

As you say, in order to manage and handle retransmissions it is safer to use a well known protocol like TCP.
Moreover, all this error handling can be accelerated by the driver's native suport for TCP, or even by TCP accelerated hardware (see http://www.intel.com/technology/ioacceleration/ for smart TCP/IP acceleration). With these, TCP becomes really efficient.

By Johan on April 16th, 2008 at 1:11 am
Thanks, sorry for posting twice. My browser came back with an error on the first try and I re-typed the message.


What do you think?

Name (required)

Email (required; will not be displayed on this page)

Your URL (optional)

Comments (required)