Subject: Re: [homegate] First Pass of Notes Attached

From: David R Oran <[email-masked]>
Date: Wed, 14 Jul 2010 13:46:00 -0400

On Jul 14, 2010, at 1:35 PM, Duncan wrote:

> Hi Dave,
> 
>  
> Regarding the QoS comments directed to HGI.
> 
> Have you read the HGI QoS whitepaper? http://www.homegateway.org/publis/HGI-GD013-R2.pdf
> 
Yes I have.

> HGI would welcome comments and suggestions if there is some way in which this architecture should be improved to help solve real-world problems. I have not encountered many requirements to have customers directly configure their HG classifiers and queues but HGI would welcome a discussion of the reasons for that.
> 
I wasn't thinking necessarily about customers doing this directly, for similar reasons why it's unrealistic to ask them to configure firewalls, but either:
- applications they use/install configure QoS traffic classifications on the routers
- an external party the user trusts (e.g. a web portal that provides performance measurement/management) that measures what their home network is doing and configures traffic classifications in a way that optimizes the user's interests (which may not be 100% aligned with those of his service provider).

>  
> If IETF would like to send a liaison to HGI on this or other issue, we will be happy to respond. (I have some homework to do in setting up the liaison arrangement but please don't let that stop you).
> 
> Or, those working for an HGI member company are welcome to bring comments directly. Finally observers are welcome at our Vancouver meeting in September -- let me know if you would like to discuss the QoS or other issues there.
> 
>  
>  
> cheers
> 
> Duncan 
> 
> 
> On Jul 14, 2010, David R Oran <[email-masked]> wrote:
> 
> Here's some more material for the marked section: "Dave Oran felt there is an interesting place for the IETF to play [WOULD LIKE MORE FROM DAVE ON THIS]. One question he had was what the presenters felt there were any gaps in their existing work."
> 
> Dave Oran feels that there are a few areas that are directly in the IETF's scope of interest and competence that are not adequately addressed by the other SDOs represented. In general, the principles for what to tackle were very well captured by JFM's slide (get the exact words from his slide) - the essence being that homegate can and should tackle the specification of what home gateways need to do and not do to provide access from the home network to critical Internet infrastructure services (e.g. DNS) and to the broadest possible range of internet applications.
> 
> In addition to fleshing out the work on IPv6 CPE that is ongoing, Dave feels that homegate ought to tackle routing and other IPv6 services (e.g. address delegation, multiple subnets, multihoming) on home networks that affect the ability to access and use resources not just in the home but on the internet as a whole.
> 
> While a number of the other SDOs do stuff in the QoS domain (especially HGI, DLNA, and IEEE) I got the nagging sense that none of these really capture the essence of the QoS architecture that the IETF has designed over many years (hence my questions to the HGI folks about users not being able to control traffic classification, and my questions about what these latency bounds IEEE AVB provides really mean). It seems to me that there is an opportunity for homegate to tackle this "inside/outside" disconnect in the QoS approaches specified by the other SDOs.
> 
> Also, during a sidebar IM conversation with Ralph Droms the issue came up of how to do a better job of naming - right now the only options for naming resources on a home network are either entirely local (e.g. UPnP or mDNS with .local) or require the user to register a domain in the DNS (either directly or through a service like dyndns) and use wide-area Bonjour, which challenges even the most astute technically to configure correctly. We really ought to have a way to name resources on home networks such that they can be globally referenced through the dns. This was of less importance in the IPv4 environment because (a)user could at some inconvenience actually type and understand IPv4 addresses, and (b) IPv4 NAT renders the ability to globally reference the resources moot.
> 
> DaveO.
> 
> 
> On Jul 13, 2010, at 1:20 PM, Jason Livingood wrote:
> 
> > Feel free to mark up. Thank you all for participating!
> > 
> > 
> > Regards,
> > Jason
> > 
> > Jason Livingood
> > Executive Director
> > Internet Systems Engineering
> > National Engineering & Technical Operations
> > Comcast Cable Communications
> > 215-286-7813
> > [email-masked] 
> > <Homegate Workshop Notes - 20100713 - v1.docx>
> 
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>

---

From: Duncan <[email-masked]>
Date: Wed, 14 Jul 2010 11:35:50 -0600 (MDT)

Hi Dave,

cheers

Duncan

DaveO.

---

From: "Duncan Bees" <[email-masked]>
Date: Tue, 20 Jul 2010 13:22:29 -0700

Hi Dave
OK thanks for the response - I misunderstood your comments then.

The idea of applications configuring the classifiers is already part of this
(for example information resulting from DHCP transactions with end devices,
or other means to identify end devices, leading to  reconfiguration of the
classifiers). 

More broadly HGI is looking at "next gen QoS" which expands the intelligence
behind these decisions and potentially moves beyond classification to more
comprehensive methods of identifying traffic classes. Providing user some
configuration choices can be part of that, but we really started this
activity in detail at our Taipei meeting in June and will have more to say
in coming months.

Cheers
Duncan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R Oran
Sent: July-14-10 10:46 AM
To: Duncan
Cc: [email-masked]
Subject: Re: [homegate] First Pass of Notes Attached

On Jul 14, 2010, at 1:35 PM, Duncan wrote:

> Have you read the HGI QoS whitepaper?
http://www.homegateway.org/publis/HGI-GD013-R2.pdf
Yes I have.

> HGI would welcome comments and suggestions if there is some way in which
this architecture should be improved to help solve real-world problems. I
have not encountered many requirements to have customers directly configure
their HG classifiers and queues but HGI would welcome a discussion of the
reasons for that.
I wasn't thinking necessarily about customers doing this directly, for
similar reasons why it's unrealistic to ask them to configure firewalls, but
either:
- applications they use/install configure QoS traffic classifications on the
routers
- an external party the user trusts (e.g. a web portal that provides
performance measurement/management) that measures what their home network is
doing and configures traffic classifications in a way that optimizes the
user's interests (which may not be 100% aligned with those of his service
provider).

>  
> If IETF would like to send a liaison to HGI on this or other issue, we
will be happy to respond. (I have some homework to do in setting up the
liaison arrangement but please don't let that stop you).
> 
> Or, those working for an HGI member company are welcome to bring comments
directly. Finally observers are welcome at our Vancouver meeting in
September -- let me know if you would like to discuss the QoS or other
issues there.
> Here's some more material for the marked section: "Dave Oran felt there is
an interesting place for the IETF to play [WOULD LIKE MORE FROM DAVE ON
THIS]. One question he had was what the presenters felt there were any gaps
in their existing work."
> 
> Dave Oran feels that there are a few areas that are directly in the IETF's
scope of interest and competence that are not adequately addressed by the
other SDOs represented. In general, the principles for what to tackle were
very well captured by JFM's slide (get the exact words from his slide) - the
essence being that homegate can and should tackle the specification of what
home gateways need to do and not do to provide access from the home network
to critical Internet infrastructure services (e.g. DNS) and to the broadest
possible range of internet applications.
> 
> In addition to fleshing out the work on IPv6 CPE that is ongoing, Dave
feels that homegate ought to tackle routing and other IPv6 services (e.g.
address delegation, multiple subnets, multihoming) on home networks that
affect the ability to access and use resources not just in the home but on
the internet as a whole.
> 
> While a number of the other SDOs do stuff in the QoS domain (especially
HGI, DLNA, and IEEE) I got the nagging sense that none of these really
capture the essence of the QoS architecture that the IETF has designed over
many years (hence my questions to the HGI folks about users not being able
to control traffic classification, and my questions about what these latency
bounds IEEE AVB provides really mean). It seems to me that there is an
opportunity for homegate to tackle this "inside/outside" disconnect in the
QoS approaches specified by the other SDOs.
> 
> Also, during a sidebar IM conversation with Ralph Droms the issue came up
of how to do a better job of naming - right now the only options for naming
resources on a home network are either entirely local (e.g. UPnP or mDNS
with .local) or require the user to register a domain in the DNS (either
directly or through a service like dyndns) and use wide-area Bonjour, which
challenges even the most astute technically to configure correctly. We
really ought to have a way to name resources on home networks such that they
can be globally referenced through the dns. This was of less importance in
the IPv4 environment because (a)user could at some inconvenience actually
type and understand IPv4 addresses, and (b) IPv4 NAT renders the ability to
globally reference the resources moot.