Subject: Re: [tsv-area] [homegate] Amount of packet buffering in home gateways

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jul 2009 08:56:00 +0200 (CEST)

I'd say that in the long run (it was like this when I deployed ethernet 
dslams 6+ years ago) we're headed for the same kind of behaviour in the 
ISP end as ETTH switches has today, ie few milliseconds of buffers and 4 
strict prio queues (think ETTH but with VDSL2 as PHY instead of 
100BASE-T).

So if the ISP->CPE path behaves like this, would it perhaps be nice to 
have the CPE->ISP direction behave the same way?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Duncan <[email-masked]>
Date: Wed, 29 Jul 2009 16:56:15 -0600 (MDT)

Hi all,

Yes, in fact HGI has looked at the QoS architecture including queue requirements and latency avoidance and have issued rather detailed recommendations that meet the Service Provider requirements for delivery of services. We would be pleased to explain the QoS approach.

E.g., we can look at setting up a conference call for HGI to explain this to the Homegate list if there is sufficient interest. If there are concerns with aspects of our work, (as implied in the message below and as stated during the Bar BoF), then we'd also welcome specific feedback.

Note that we have a Test Event in the near future to look at implementations of the HGI QoS requirements.

Best Regards

Duncan

Duncan Bees

Chief Technical & Business Officer, Home Gateway Initiative Vancouver, Canada [email-masked] or [email-masked] mobile +1.604.418.8997

skype: duncan.bees1

www.homegateway.org

On Jul 29, 2009, Richard Bennett <[email-masked]> wrote:

David R Oran wrote:
> HGI and others (e.g. DLNA) do in fact have specs for this kind of
> stuff. I'll refrain from commenting on what I think of their quality.
> I think the group might consider taking some of this on, however I
> urge caution for a number of reasons including:
> - focus for the group
> - bleed-over into net neutrality issues
> - service definition and provisioning of device queues by the service
> provider versus the consumer.
I'm not sure what Homegate has to do with "net neutrality issues." If
net neutrality means anything at all, it's the demand by certain private
network operators, most notably Google, to have unfettered access to
first/last mile residential broadband networks. Google wants to bypass
the public Internet and install edge caches directly on the L2 network,
in other words. Aren't private network-to-private network issues are
outside the scope of IETF?

Under other definitions of net neutrality, ISP behavior is circumscribed
in various ways, but end-user behavior isn't. Given that home gateways
are (at least to some extent) end-user controlled devices, NN also
wouldn't apply to them under this more fuzzy definition.

NN is in any case a US issues, so I don't see why the international
community should care about it. What am I missing?

RB

--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC

_______________________________________________
homegate mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homegate

---

From: Richard Bennett <[email-masked]>
Date: Thu, 30 Jul 2009 04:07:08 -0700

IEEE 802.11e specifies four strict levels of priority as well, as these 
are validated by the Wi-Fi Alliance WMM compliance suite. The IEEE 
standard tells how to map these four levels onto the 802.1q priorities 
as well. Similar systems exist for MoCA and Home Plug. So my answer 
would be yeah, let the user have control over the priority of the 
transmissions he sends from his home or office LAN to his ISP, and let 
the ISP handle them as well as they're able. Diffserv can carry these 
markings as far as it goes, and with the right kind of peering or 
transit agreements, that might be a very long way.

RB

Mikael Abrahamsson wrote:
>
> I'd say that in the long run (it was like this when I deployed 
> ethernet dslams 6+ years ago) we're headed for the same kind of 
> behaviour in the ISP end as ETTH switches has today, ie few 
> milliseconds of buffers and 4 strict prio queues (think ETTH but with 
> VDSL2 as PHY instead of 100BASE-T).
>