Subject: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area

From: Bhumip Khasnabish <[email-masked]>
Date: Sat, 5 Mar 2011 15:51:25 -0500

Dear All,

Based on multiple discussions that we had in [email-masked] and suggestions
/ recommendations
from IETF APP area AD (Peter), we plan to focus former CloudApps work in the
proposed
virtual desktop infrastructure (VDI) area.

Below pls find the draft charter we are developing based on participation
and contribution of those
who are interested in this.

The clear and present trend of end-user device convergence merges multiple
information processing devices, communication devices, and entertainment
devices into a single unit.  This highly converged device is supported by
the Virtual Desktop Infrastructure (VDI) in the virtual on-demand computing
and networking environment (commonly referred to as Cloud environment). VDI
consists of the following three basic functional components:  Virtual
Desktop Client (VDC, the converged end-user device), the Virtual Desktop
Agent (VDA, the control software residing in a virtual machine hosted in a
data center), and a set of protocols connecting them together to deliver the
desired services.

                                     +---------------------------+

                                     | +-----------------------+ |

        +-----------+  VDI protocol  | | +------------------+  | |

        | VDI Client|----------------+ + | Virtual Desktop  |  | |

        +-----------+                | |       Agent        |  | |

                                     | | +------------------+  | |

                                     | |      Guest OS         | |

                                     | +-----------------------+ |

                                     |   Virtual Machine         |

                                     | Hosted in a Data Center   |

                                     +---------------------------+

Currently there are no standard VDI protocols.  This lack of standard
protocol creates friction and barrier in solution development, deployment,
and service management.  In addition, the limited available proprietary
solutions do not fully address the issues caused by service mobility
and   access
(both nomadic and wireless).  Furthermore, many critical functional
requirements for VDI such as service availability/distribution, scalability,
security, and manageability are not addressed in a way to support
interoperability.

The proposed VDI WG focuses on the requirements and protocol development
activities that are directly associated with virtual desktop infrastructure.
The background materials related to SDO survey, reference framework, work
items gap, and security gap can be found in the already
published/work-in-progress (to be completed soon) drafts as cited at the end
of this document.

The proposed work items for the VDI WG are as listed below.

1) Produce a VDI Problem Statement and Resolution document listing the
technical issues of the existing VDI systems, proposing reference
architecture, and defining the scope of VDI protocol standard.

2) Produce a VDI Requirements document that defines the functional and
operational requirements of the VDI protocol.

3) Produce a detailed VDI Protocol Specification.

4) Once the base protocol specification is complete, re-charter the WG to
produce various VDI protocol extensions to support application-specific
areas such as access security, additional video/audio compression mechanism,
service mobility, profile/personality adjustment, and context-awareness.

*References and VDI-related drafts:*

Ø  http://tools.ietf.org/id/draft-wang-clouds-vdi-problem-statement-00.txt

Ø  http://www.ietf.org/id/draft-cloud-log-00.txt

Ø
http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Johnston-IETF-78-Clouds-bar-BoF-Std-Gap-28July10.pdf

Ø
http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Protocol%20Considerations%20for%20Workload%20Mobility%20in%20Clouds.txt

Ø
http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/draft-rfc-seamless-Cloud-masum-01.txt

Ø  Karavettil-et-al-IETF-VDI-Draft-v1-03042011

*Background References and drafts:*

Ø  http://tools.ietf.org/id/draft-ma-clouds-vdi-survey-00.txt

Ø  http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-00.txt

Ø
http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-00.txt

Ø
http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-00.txt

Ø  http://tools.ietf.org/id/draft-so-vepc-01.txt

Ø
http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/Karavettil-et-al-IETF-Cloud-Security-Framework-11Feb2011_v2.pdf

All of the drafts and presentations are available at the following site:

http://trac.tools.ietf.org/area/app/trac/wiki/Clouds

We  look forward to your further comments and suggestions.

Many thanks.
Best Regards.

Bhumip Khasnabish (Mobile:+001-781-752-8003, [email-masked])
http://www.linkedin.com/in/bhumipkhasnabish

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 05 Mar 2011 15:11:20 -0800

First off, I think this work could be very useful both in the short and 
long run. I am swimming in these issues today in my work, so please do 
not take the response below as diminishing the need.

I question whether or not the IETF would be the best place for this. I 
say that not because "SDO X would be better than the IETF" because if 
that were the case, SDO X would have done so by now. However, most of 
the interesting work here is, in fact, an API. Note that I am *not* one 
of the people who says "the IETF { doesn't / can't } do APIs"; I think 
we do/can as long as we are upfront about it.

In specific (a fixed chart):

+-----------+                | | |     Agent        |  | |

Given that the text of the proposed charter says that the protocol would 
be between the VDI Client and the Virtual Desktop Agent", which might be 
software running on a Guest OS with no network connectivity, this will 
be an API unless there is a requirement that the Guest OS has network 
connectivity at a known and predictable address, and that the Virtual 
Machine (actually, the host system) also has network connectivity at a 
known and predictable address, and neither is firewalled from the VDI 
client.

A different model would be that the VDI Client has a new protocol to 
talk to the host system, and that the host system has an API for talking 
to the Guest OS in a way that would reach the Virtual Desktop Agent. 
This model has some advantages over the narrow one in the charter. For 
example, the protocol would allow control over Guest OSs, such as "start 
up machine X" and "send text to the console on machine X". These will 
work even if the Guest OS does not support the API, or if it does not 
currently have network connectivity.

The proposed WG could come up with requirements for both the 
client-to-host protocol and the API between the host and the desktop 
agent, and the two could clearly have some good interactions.

(And for those of you who want to come up to speed on the terminology 
used in virtualization and some of the security issues, please see NIST 
SP 800-125 
<http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf>.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bhumip Khasnabish <[email-masked]>
Date: Fri, 4 Mar 2011 11:13:18 -0500

Dear All,

                                     | |      Guest OS         | |

                                     |   Virtual Machine         |

Ø

Ø

Ø

Ø

Ø

Ø

Many thanks.
Best Regards.

---

From: John Levine <[email-masked]>
Date: 6 Mar 2011 00:10:06 -0000

>Currently there are no standard VDI protocols.

Isn't the de-facto standard VNC? It will be RFC 6143, probably coming
out this week.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 05 Mar 2011 16:23:54 -0800

> Isn't the de-facto standard VNC? It will be RFC 6143, probably coming

VNC covers one part of what is being described, namely the KVM control 
of the guest OS. The proposal Bhumip sent goes well beyond that control, 
and the one I propose goes beyond what Bhumip has proposed.

--Paul Hoffman

---

From: Scott W Brim <[email-masked]>
Date: Mon, 7 Mar 2011 19:17:48 -0500

On Sat, Mar 5, 2011 at 18:11, Paul Hoffman <[email-masked]> wrote:

>  However, most of the interesting work here is, in fact, an API. Note that
> I am *not* one of the people who says "the IETF { doesn't / can't } do
> APIs"; I think we do/can as long as we are upfront about it.
>

Right.  Personally I believe it's fine for the IETF to do APIs that enable
capabilities closely associated with the network.  I see no problem doing
this.

> Given that the text of the proposed charter says that the protocol would be
> between the VDI Client and the Virtual Desktop Agent", which might be
> software running on a Guest OS with no network connectivity, this will be an
> API unless there is a requirement that the Guest OS has network connectivity
> at a known and predictable address, and that the Virtual Machine (actually,
> the host system) also has network connectivity at a known and predictable
> address, and neither is firewalled from the VDI client.
>
> A different model would be that the VDI Client has a new protocol to talk
> to the host system, and that the host system has an API for talking to the
> Guest OS in a way that would reach the Virtual Desktop Agent. This model has
> some advantages over the narrow one in the charter. For example, the
> protocol would allow control over Guest OSs, such as "start up machine X"
> and "send text to the console on machine X". These will work even if the
> Guest OS does not support the API, or if it does not currently have network
> connectivity.
>
> The proposed WG could come up with requirements for both the client-to-host
> protocol and the API between the host and the desktop agent, and the two
> could clearly have some good interactions.
>

If I understand you correctly, I just want to be sure functions are
decoupled.  The client SHOULD NOT know whether its agent is in a particular
environment, e.g. a VM / Guest OS.  Environments need to be replaceable, and
the VDI or VDIs must be able to change independently.  No?  So I think it's
okay to just focus on just the relationship between client and agent to
start with, and possibly bring other things in as they turn out to be
useful.

Scott

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Mar 2011 19:47:29 -0700

<hat type='individual'/>

On 3/5/11 4:11 PM, Paul Hoffman wrote:
> that were the case, SDO X would have done so by now. 

Paul, I'm not sure that follows. :) Many factors are involved in the
standardization (or lack thereof) within a particular problem domain.

> However, most of

Another question is: can we do it well? And, more specifically, do we
have reason to think that we might do it well in the virtual desktop
infrastructure (VDI) space?

> In specific (a fixed chart):

Roughly what percentage of Guest OS and VM systems have network
connectivity of the kind that would enable use of a protocol instead of
an API? That might be helpful information.

> currently have network connectivity.

Yes, that does seem like a powerful model. Roughly what percentage of
VDI systems are architected that way currently, as opposed to the model
outlined in the proposed charter? How does what you've described differ
from draft-wang-clouds-vdi-problem-statement-00?

(And as I'm sure you've thought about, the security considerations might
get "interesting" if the VDI client has permissions to do things at the
host level.)

> agent, and the two could clearly have some good interactions.

In your opinion, which would come first -- the protocol or the API?

> <http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf>.

Thanks for providing the reference.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Mar 2011 21:54:51 -0700

Paul, I'm sure I should be embarrassed to ask this and it is somewhere in my inbox ... but do you have point to the two proposal from you and Bhumip. Thanks, Cullen

On Mar 5, 2011, at 5:23 PM, Paul Hoffman wrote:

> VNC covers one part of what is being described, namely the KVM control of the guest OS. The proposal Bhumip sent goes well beyond that control, and the one I propose goes beyond what Bhumip has proposed.
> 
> --Paul Hoffman
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Mar 2011 21:59:10 -0700

> Paul, I'm sure I should be embarrassed to ask this and it is somewhere in my inbox ... but do you have point to the two proposal from you and Bhumip. Thanks, Cullen

That would be:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02309.html

and

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02310.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 09 Mar 2011 08:26:23 -0800

> infrastructure (VDI) space?

That is a very good question, and the answer depends on where you think 
the VDI protocol's endpoint it. The proposed charter has it being an 
agent in the Guest OS. As John Levine points out, this is essentially 
VNC (for which we now have RFC 6143) and/or Microsoft's RDC. It actually 
has nothing to do with "virtual" at all: it works as well for OSs 
running on real boxes as it does for guest OSs running in a hypervisor.

FWIW, I think that RFC 6143 could be extended to have some other 
features that are useful, such as file transfer and better security. But 
I don't think the IETF has any special knowledge (or lack thereof) for 
such extensions.

If you think that the VDI ends at the hypervisor, as I have proposed, 
this becomes a protocol that is more in line with the normal IETF work.

> an API? That might be helpful information.

It is safe to assume that all hypervisors have network connectivity. The 
interesting question is for the guest OSs, and there are multiple 
answers. Many guest OSs have network connectivity to other guest OSs but 
not to the Internet: they are by design on switches with no contact 
outside the LAN. Some guest OSs are dual-homed, acting as gateways / 
firewalls / routers for other guest OSs on their LAN. And an 
often-ignored scenario is a guest OS that has no network connectivity 
because it is coming up for the first time or has been purposely pulled 
off all networks for security reasons.

> outlined in the proposed charter?

All. That is, all hypervisors have methods to start up guest OSs, shut 
them down, and so on. Some have CLI languages to do so; a good example 
is VirtualBox's VBoxManage CLI.

> How does what you've described differ

It's hard to say, but I don't see anything in that draft the requirement 
to control the hypervisor. It seems like the draft is really about 
supplanting VNC and RDC. Again, that might be a useful exercise, but the 
draft does not address whether it is better to just extend VNC or to 
start fresh.

> get "interesting" if the VDI client has permissions to do things at the

Of course they have those permissions: that's what the entire draft is 
about. You want to be remote hands on the guest OS.

> In your opinion, which would come first -- the protocol or the API?

The protocol. The API already exists in VNC and RDC. Defining how the 
protocol interacts with the APIs is quite easy relative to defining what 
needs to be in the protocol itself.

OTOH, if there is not much interest in defining the protocol, I don't 
think a WG is needed.

---

From: [email-masked]
Date: Thu, 10 Mar 2011 14:24:10 +0800

Hi peter & all,
   I have replied Paul's mail once, but rejected by the app-discuss 
maillist, so I'm trying again here.
   At the section 2.1 in the problem statement draft, both VDA in the 
guest OS and in the host have been briefly discussed. 
   Regarding the APIs between VDA and host system, I think most of them 
are existing device I/O specifications and hardware platform specific, 
which should be left for system developers' decision. Actually, without 
any additional software installed in the guest, the host VDI model still 
works well, although not very well.

Russell

> Thanks for providing the reference.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.