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

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 7 Aug 2009 11:59:50 -0700

The manufacturers would benefit from specific guidance -- if we could
say that the right value were 10 packets or 10kB or 100ms worth of
serialization delay, rounded up to an integer number of packets or
some such, they could implement it.

Trouble is, we don't know any such right value.

What we do know are things like:

* Even a single TCP flow on a very slow link will need a few packets
worth of buffer so that it can keep something in flight and so that
fast retransmit works.  Different values have been argued to be right
from this perspective, from 6 packets to 10.

* Multiple TCP flows likely need more buffer, but probably not much
more, because it becomes increasingly acceptable for fast retransmit
to fail and timeout to fire when there are more connections -- they're
probably going to keep the link busy anyway.

* Any of that is way too much from the POV of delay experienced by
interactive apps (interactive = user waiting, so includes web).

The conjunction implies a lack of right value.  In absence of such,
best we could hope for is giving negative guidance.  We do know that a
64-kB buffer on a 128-kb/s link serves no purpose and could write it
up and explain why.  We'll end up with excessively conservative
recommendations this way, but maybe it's OK.

If we can't agree on specific guidance that people can use to size the
buffers and instead can only agree on general considerations like ones
I listed above, we might be better off not issuing any guidance at all
in the spirit of doing no harm.  After all, if we can't translate that
into bytes (which a manufacturer ultimately must), why should we
expect others to do so?

On Wed, Jul 29, 2009 at 1:59 AM, james woodyatt<[email-masked]> wrote:
> On Jul 29, 2009, at 10:34, Iljitsch van Beijnum wrote:
>>
>> The question is, what do we want to tell home gateway builders?
>
> We should tell them that forwarding IP flows from higher bandwidth links
> into much lower bandwidth links generally produces better results when
> queues are only large enough to handle common burst sizes without loss and
> no larger.  Unnecessarily large transmission queues may introduce
> persistently and perversely high path latency on fully loaded low-bandwidth
> links, producing severe negative effects on application throughput.
>
> Beyond that, I don't know what else we should say.  Maybe it would help to
> give some guidance for various common sub-IP links.
>
>
> --
> james woodyatt <[email-masked]>
> member of technical staff, communications engineering
>
>
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Lars Eggert <[email-masked]>
Date: Sat, 8 Aug 2009 10:29:07 +0300

Hi,

these are all good points. I wanted to repeat something I said at the  
mike in Stockholm which I think is essential:

We cannot make a recommendation for a certain buffer size without also  
saying which queuing scheme we recommend for that buffer.

If we assume that FIFO queuing will be used, yes, the buffer size has  
a large, direct impact on the observable behavior. Not so for various  
AQM schemes (RED, etc.). Since my personal preference would be to  
recommend something smarter than FIFO, I don't see buffer size as very  
critical then. (Now, how to correctly parameterize an AQM scheme for a  
given link, *that* would be critical...)

Lars

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 8 Aug 2009 09:54:36 +0200 (CEST)

On Sat, 8 Aug 2009, Lars Eggert wrote:

> If we assume that FIFO queuing will be used, yes, the buffer size has a 
> large, direct impact on the observable behavior. Not so for various AQM 
> schemes (RED, etc.). Since my personal preference would be to recommend 
> something smarter than FIFO, I don't see buffer size as very critical 
> then. (Now, how to correctly parameterize an AQM scheme for a given 
> link, *that* would be critical...)

Hi, in some discussion that came up during the IETF I talked about my home 
scheme, so just to give an example of a heuristic that I personally have 
found to work well in Cisco MQC (not proposing something concrete, just 
giving an example):

class-map match-all small-packets
  match packet length max 200
class-map match-all prio-data
  match access-group name outgoing-prio-data

policy-map out-child
  class prio-data
     bandwidth 300
  class small-packets
     bandwidth 300
  class class-default
     fair-queue 1024
      random-detect
      random-detect ecn
policy-map out-parent
  class class-default
     shape average 700000
   service-policy out-child

ip access-list extended outgoing-prio-data
  permit tcp any any eq 22
  permit udp any any eq domain
  permit icmp any any
  permit ospf any any
  permit tcp any any eq telnet
  permit tcp any any eq www
  permit 41 any any

So basically, I have 1 meg upstream on my cable modem and since I have no 
influence on the buffering there (and the shaping I'm doing is on a ipip 
tunnel), I make sure I use way less than my bw and then I assure a minimum 
bw to outgoing packets to a few services/ports on the Internet 
(ssh/dns/telnet/http), then I also assure a certain amount of bw to 
smaller packets (to catch the typical ACKs and smaller packets typically 
seen in interactive applications such as VOIP and others), then everything 
else is going into fair-queue with WRED and ECN (yes, I actually use ECN 
because I wanted to test it :P)).

This queuing scheme is actually very helpful even on faster links, because 
if you have a T3 link (45 meg) and do FIFO on it with good TCP windows on 
the end hosts, a single TCP flow can make this jump to 100+ ms buffer 
easily, thus you want fair-queue to make it do something intelligent with 
the different flows to avoid your SSH traffic sitting behind this 100ms of 
file transfer. Thus I think any proposal should recommend/inform about 
this even for 100 meg uplinks and higher, as soon as you have big buffers 
you want to do something intelligent queuing where the higher speeds you 
have and lesser buffers, the less intelligence is needed.

I tried replicating this using "tc" in Linux a few years back but gave up 
after a few hours because I just couldn't make it work, so anyone being a 
master at that, I'd be very helpful translating this into "tc" conf :)

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sat, 08 Aug 2009 20:45:56 -0700

Hi, all,

Has anyone raised the potential need for fair-sharing in home gateways?
I.e., to prevent a single home user from swamping out another home user?

(we saw this in a gateway Lars, Yu-shun Wang, and I developed, FWIW,
when we used it to support demos at workshops).

Joe

---

From: David R Oran <[email-masked]>
Date: Sun, 9 Aug 2009 11:36:01 -0400

On Aug 8, 2009, at 11:45 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, all,
>
If one can define "user" in a technically useful way, then it may or  
may not be feasible. If one can't define "user" then I don't know  
where to start.

If user==host, then there may be a way to cover the simple cases - but  
even that's a bit tricky without some kind of signaling protocol.

I think I know how to do this with MPLS :-)

Also a challenge with IPv6 is the ease with which host addresses an be  
manufactured.

Alternatively, if one posits in-home VLANS (like I have in my house),  
then I can pretty easily carve things up. But I suspect we don't want  
to got there either :-)

I'm all ears if somebody has a proposal to make.

Note also, that we have so many easy problems to tackle, if this one  
turns out to be difficult I'd be loathe to make it in scope.

DaveO.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkp+RnQACgkQE5f5cImnZrs18gCg9OGS9559T494JHZbxFnuTj+n
> 9kwAoNKVBt30NYxAt/6w4w+wJ428HHUa
> =AJQg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: Joe Touch <[email-masked]>
Date: Sun, 09 Aug 2009 08:55:44 -0700

David R Oran wrote:
>> If one can define "user" in a technically useful way, then it may or may
>> not be feasible. If one can't define "user" then I don't know where to
>> start.
> 

User = IP address (i.e., just to keep it simple). And that's already
supported in FreeBSD, so I doubt it's that tricky.

>> then I can pretty easily carve things up. But I suspect we don't want to
>> got there either :-)

Even fair corresponding to NAT'd address is useful. It doesn't have to
be perfectly fair, it just prevents one user from crowding everyone else
out due to non-reacting flows.

>> turns out to be difficult I'd be loathe to make it in scope.

It's not difficult; it just needs to be spec'd, and the spec doesn't
need to be precise. The goal is to do something that is per address at
least, and prevents crowding out, and that's already supportable in at
least one existing OS.

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 13:40:43 -0700

Lars,

Right.  Two separate points here:

1. With AQM, one needs to replace "buffer" in my statements below with  
"occupied buffer".  This will presumably be controlled by AQM  
parameters (a drop low watermark or whatnot).  The statements still  
stand: no amount of AQM is going to make TCP dynamics better with a  
single-packet window, for example.  The core problem of having to have  
a few packets in flight per flow and that translating to a large  
serialization delay stands.  If anything, it's ECN that could help  
here, not AQM.

2. I didn't mention AQM because I don't believe we should recommend  
one.  We should not do RED, because it's clear by now that it's  
suboptimal.  We should not do something other than RED, because  
homegate isn't the place.

Thanks,  -- Stas

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

On Aug 8, 2009, at 12:29 AM, Lars Eggert wrote:

> Hi,
>
> these are all good points. I wanted to repeat something I said at  
> the mike in Stockholm which I think is essential:
>
> We cannot make a recommendation for a certain buffer size without  
> also saying which queuing scheme we recommend for that buffer.
>
> If we assume that FIFO queuing will be used, yes, the buffer size  
> has a large, direct impact on the observable behavior. Not so for  
> various AQM schemes (RED, etc.). Since my personal preference would  
> be to recommend something smarter than FIFO, I don't see buffer size  
> as very critical then. (Now, how to correctly parameterize an AQM  
> scheme for a given link, *that* would be critical...)
>
> Lars
>

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 13:46:36 -0700

On Aug 9, 2009, at 8:55 AM, Joe Touch wrote:

> User = IP address (i.e., just to keep it simple).

In a typical home deployment, there's just one IP address visible to  
the home gateway (e.g., cable/DSL modem): the address that the home  
router has acquired.  The actual machines, phones, game consoles,  
etc., are behind a NAT.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: David R Oran <[email-masked]>
Date: Sun, 9 Aug 2009 18:32:24 -0400

> router has acquired.  The actual machines, phones, game consoles,  
But those ARE visible to the outbound queueing machinery of the HG,  
and hence the queues facing the uplink could have finer policy.

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 15:40:31 -0700

Perhaps a picture will help clarify:

home devices <-- ~25Mb/s (wifi) --> router <-- 100Mb/s --> homegate  
<-- 0.4 Mb/s --> Internet

The router is the NAT.  The homegate is the headend of the congested  
link.

In a typical home situation, the router is a Linksys base station/NAT  
box and the homegate is something like a Motorola cable modem.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

On Aug 9, 2009, at 3:32 PM, David R Oran wrote:

>> In a typical home deployment, there's just one IP address visible  
>> to the home gateway (e.g., cable/DSL modem): the address that the  
>> home router has acquired.  The actual machines, phones, game  
>> consoles, etc., are behind a NAT.
>>

---

From: Joe Touch <[email-masked]>
Date: Sun, 09 Aug 2009 17:25:14 -0700

Stanislav Shalunov wrote:
> In a typical home deployment, there's just one IP address visible to the
> home gateway (e.g., cable/DSL modem): the address that the home router
> has acquired.  The actual machines, phones, game consoles, etc., are
> behind a NAT.

The addresses that I'm thinking of keeping track of would be those on
the home side, for all the machines behind the device. NATd or not,
doesn't matter - it's the same problem.

Think of it this way. You have a home gateway, and your Tivo goes
berzerk with UDP packets to the Internet; you don't want that starving
out your laptop's email, or anything else.

This is less about being truly 'fair', since any fairness scheme can be
gamed. It's about preventing starvation...

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 09 Aug 2009 17:27:16 -0700

Stanislav Shalunov wrote:
> home devices <-- ~25Mb/s (wifi) --> router <-- 100Mb/s --> homegate <--
> 0.4 Mb/s --> Internet
> 
> The router is the NAT.  The homegate is the headend of the congested link.
> 

In the typical home situation, I expect the wifi, router, and homegate
all in one box (they are for everyone I know).

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 18:01:49 -0700

> all in one box (they are for everyone I know).

Most home users with better-than-dialup are connected with cable or DSL.

The vast majority of them use wifi and NAT.

The cable/DSL modems provide neither wifi nor NAT services.

This makes for a typical situation with two boxes.

The only technology that would enable home connectivity with one box  
would be something supported by the common home routers.  Which only  
support Ethernet on the uplink.  Ethernet is not commonly used to  
deliver home Internet service in the United States.

The node that you might be thinking of is the router/NAT/wifi box.   
This box is not at a head end of a congested bottleneck.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Richard Bennett <[email-masked]>
Date: Sun, 09 Aug 2009 18:06:34 -0700

I agree with Joe, nobody considers a standalone DSL "modem" or DOCSIS
modem to be the home gateway, the NAT/Etherswitch/Wi-Fi AP is the home
gateway. Let's be clear about basic terminology. Many home gateways
have the DSL modem built-in these days, and in fact nobody is
developing new DSL modems that aren't integrated with a NAT. Some NATs
do have DOCSIS built-in, but this is less common because DOCSIS is
expensive to develop and test.

Many home gateways do in fact use VLANs on both the upstream and
downstream side, especially the CPE gateways that are part of a
triple-play system with VOD to STBs inside the home. Some that I've
seen use VLANs to carry packets from one of the Virtual BSS's on the
Wi-Fi AP to a carrier NAT outside the home as well. VLANs are an
excellent way to prioritize and de-prioritize packets.

Similarly, Wi-Fi has a system of frame prioritization called WMM that
uses a subset of the 802.11e standard. It's widely supported in home
gateways these days, along with systems for shallow packet inspection
that allow users to boost the priority of Skype and lower the priority
of P2P, for example. Many P2P systems are not well domesticated.

RB

Joe Touch wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp/aWQACgkQE5f5cImnZrslLQCbBTyHL8THpjCYnfplIDtvVdA9
BLsAoLI9sOv2k0NQEEMwZkSapVdO72W7
=9gTY
-----END PGP SIGNATURE-----

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

---

From: Richard Bennett <[email-masked]>
Date: Sun, 09 Aug 2009 18:08:16 -0700

Some DSL systems use PPPoE, FWIW, and FiOS has an Ethernet interface 
between the ONT and the NAT, alongside a MoCA interface, pick one.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 9 Aug 2009 18:15:43 -0700

>This makes for a typical situation with two boxes.

Is there any published research to back up these assertions? They go against what I am familiar with in the home DSL world, namely DSL modem/gateway combos.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 18:43:07 -0700

On Aug 9, 2009, at 6:06 PM, Richard Bennett wrote:

> I agree with Joe, nobody considers a standalone DSL "modem" or  
> DOCSIS modem to be the home gateway, the NAT/Etherswitch/Wi-Fi AP is  
> the home gateway

The standalone modems are the head ends of the congested bottleneck  
leading up from the home.  They are the devices where buffer size  
matters.

> [...]
>
> Similarly, Wi-Fi has a system of frame prioritization called WMM  
> that uses a subset of the 802.11e standard. It's widely supported in  
> home gateways these days, along with systems for shallow packet  
> inspection that allow users to boost the priority of Skype and lower  
> the priority of P2P, for example. Many P2P systems are not well  
> domesticated.

I think you'll find Skype is P2P.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Dan White <[email-masked]>
Date: Sun, 9 Aug 2009 20:31:07 -0500

>Is there any published research to back up these assertions? They go against what I am familiar with in the home DSL world, namely DSL modem/gateway combos.

Me too.

For the last 5 years we've only deployed ADSL 2+ modems that are wireless
(and NAT) capable.

Now we've got a bad taste in our mouths from all the support tickets we've
had to volley.

All modem vendors we've spoken to in the last several months have
integrated wireless into most of their models, and seem to scratch their
heads when we ask for non-wireless capable modems. Finding VDSL2 or ADSL
bonded modems without built-in wireless is actually pretty dificult.

-- 
Dan White
BTC Broadband

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 19:57:14 -0700

On Aug 9, 2009, at 6:15 PM, Paul Hoffman wrote:

> Is there any published research to back up these assertions? They go  
> against what I am familiar with in the home DSL world, namely DSL  
> modem/gateway combos.

Of the unscientific sample of DSL lines ordered within last year that  
I could quickly query, 12 installs came without wifi or NAT -- and 0  
came with.  This only covered two local telcos though, so it's  
possible that others put different boxes in.

No cable modems came sporting antennas either.

Since you're in the home DSL world, which local telcos install modems  
with wifi and NAT and what is the fraction of the installed base?

However, this is only an upper bound on the right metric.  If the  
modem boxes ship with wifi/NAT, but then a user puts in a Linksys/D- 
Link/Netgear box between that and the home devices, the unconfigured  
presence of wifi/NAT in the modem is not relevant.

So, going from the other end, let's look at how many boxes, say,  
Linksys sells.  Those are all second boxes that go on top of the  
simple "modems".  I can't seem to find if Cisco breaks out Linksys  
sales, but last year before acquisition (according to http://www.techedgeezine.com/cisco_buys_linksys_1.htm) 
  Linksys had annual sales of $429M with 22% market share.  This  
suggests that tens of millions of second boxes were sold then annually  
(~20M boxes at $100/box, the real price is lower, but some revenue  
must have been from other products, so this should be a wash).  With  
an MTBF of 5 years, that puts most broadband households behind a  
second box.

(Our friends from Cisco might be able to point out the more recent  
sales figures of something like WRT54 series and similar and market  
share for Linksys if that stuff is public, but this is enough for the  
back of the envelope.)

D-Link and Netgear don't break out home networking, but overall  
revenues with guesstimates of share of revenue and market share seem  
to jibe.  I'm not going to put that in this message, already too long.

http://www.corpasia.net/taiwan/2332/annual/2007/EN/AR2007-1.pdf
http://investor.netgear.com/secfiling.cfm?filingID=950134-07-4560

But we're digressing.  Long story short:

	The buffer size that matters is at the head end of the congested  
bottleneck.

	The Amazon top-selling "modem" (http://www.amazon.com/Motorola-Surfboard-SB5101-Cable-Modem/dp/B000JV9LUK/ 
) is at the head end of a congested bottleneck.

	The Amazon top-selling home "router" (http://www.amazon.com/Linksys-WRT54G2-Wireless-G-Broadband-Router/dp/B0014J07R2/ 
) is not usually at the head of a congested bottleneck.

	HOMEGATE should care about the former device and should not care  
about the latter.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Sun, 9 Aug 2009 21:48:41 -0700

> I.e., to prevent a single home user from swamping out another home  

Non-technological solutions are often more useful in the home.  If one  
user
is mom and the other user is Johnny, then mom will tell Johnny to shut  
down
the bittorrent so she can do her work.  We saw that in an ethnographic  
study
of home users last year.  We can rely on social controls for home  
networking
and should consider how to make use of them.

Mark

---

From: [email-masked]
Date: Mon, 10 Aug 2009 08:15:57 +0100

>    The Amazon top-selling "modem" (http://www.amazon.com/Motorola-
> Surfboard-SB5101-Cable-Modem/dp/B000JV9LUK/ 
>    The Amazon top-selling home "router" (http://www.amazon.com/
> Linksys-WRT54G2-Wireless-G-Broadband-Router/dp/B0014J07R2/ 

IMHO, you've got this completely the wrong way around.

HomeGate is about making sure that the unit that provides the IP gateway 
function (be that a router or a NAT) works properly.  The focus is on the 
"router", and not on the "modem".

HomeGate is _not_ only about congestion management and queueing, if 
anything that's a very small part of the remit.  Where it is relevant is 
in making sure that the relatively smart router doesn't throw packets out 
of its WAN port faster than the dumb modem can handle.  That should 
provide far better queueing than the modem could manage by itself, but in 
effect does make the router "at the head end" of the bottleneck.

FWIW, the European market is completely dominated by combined devices with 
integrated DSL modems.  In the US there's many more standalone gateway 
devices (with ethernet on both sides) although AIUI the increasing 
provision of DSL services is changing this.  This is why when writing 
SAC035 I worked with the former and my US co-author worked with the 
latter.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 10 Aug 2009 09:54:44 +0200

Stanislav Shalunov wrote:

> Of the unscientific sample of DSL lines ordered within last year that I 
> could quickly query, 12 installs came without wifi or NAT -- and 0 came 
> with.  This only covered two local telcos though, so it's possible that 
> others put different boxes in.

A quick check of the biggest consumer-market ISP's here shows that their
current default offering is a modem that does NAT, WiFi and quite often
VoIP.  One usually gets such a modem for free.

> So, going from the other end, let's look at how many boxes, say, Linksys 
> sells.  Those are all second boxes that go on top of the simple 
> "modems".  I can't seem to find if Cisco breaks out Linksys sales, but 
> last year before acquisition (according to 
> http://www.techedgeezine.com/cisco_buys_linksys_1.htm) Linksys had 
> annual sales of $429M with 22% market share.  This suggests that tens of 
> millions of second boxes were sold then annually (~20M boxes at 
> $100/box, the real price is lower, but some revenue must have been from 
> other products, so this should be a wash).  With an MTBF of 5 years, 
> that puts most broadband households behind a second box.

I'd think that a fair number of those 20M boxes are being used in offices
and such.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Belgium: an unsolvable problem, discussed in endless meetings, with no
          hope for a solution, where everybody still lives happily.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Aug 2009 12:56:50 +0200

> The cable/DSL modems provide neither wifi nor NAT services.

A very common (the most common? at least in my perception...)  
configuration in Europe is a single box that combines DSL modem, NAT,  
WiFi AP and, if part of a phone line replacement offering, some SIP/ 
RTP to legacy telephony gateway (POTS, ISDN sockets).  Just to give  
one (popular) example of such a box: Speedport W503V, € 2 when ordered  
with a new DSL line.

That's what most people here are likely to have in mind when they hear  
the term "home gateway".
(I think that term simply is unsalvageable.)

Gruesse, Carsten

---

From: Steven Blake <[email-masked]>
Date: Sun, 9 Aug 2009 23:53:00 -0400

> given link, *that* would be critical...)

802.1Qbb (http://www.ieee802.org/1/pages/802.1bb.html) priority PAUSE
has the right semantics to push the queues back into the hosts where
they can react intelligently.  Unfortunately, this would require
more-or-less universal adoption in modems, gateways, switches, hosts,
and WiFi APs.

Regards,

/////////////////////////////////////////////
Steven Blake       [email-masked]
Extreme Networks              +1 919-884-3211

---

From: David R Oran <[email-masked]>
Date: Mon, 10 Aug 2009 07:54:24 -0400

On Aug 9, 2009, at 11:53 PM, Steven Blake wrote:

>> also
Well, if you can put the algorithms into the home gateway to know when  
to send PAUSE, you can by definition manage the queues intelligently  
in the home gateway itself. I don't see how this changes anything -  
unlike in localized L2 networks, in an IP network bottlenecks can be  
anywhere on the path. There's nothing special about the second hop  
that pushing the congestion notification one hop upstream solves  
anything.

Take this to the extreme (no pun intended) and you wind up with X.25  
backward congestion notification.

Cheers, DaveO.

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2009 07:14:19 -0700

Mark Baugher wrote:
>> Non-technological solutions are often more useful in the home.  If one user
>> is mom and the other user is Johnny, then mom will tell Johnny to shut down

That works only when Mom knows Johnny is doing something like that.

Further, I don't see why social controls are useful when a trivial
mechanism is sufficient.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2009 07:26:13 -0700

Carsten Bormann wrote:
> WiFi AP and, if part of a phone line replacement offering, some SIP/RTP
> to legacy telephony gateway (POTS, ISDN sockets).  Just to give one
> (popular) example of such a box: Speedport W503V, € 2 when ordered with
> a new DSL line.

I have a Westell VersaLink model 327W, which I've used for several
years, as have many Verizon customers. Like modems I've had since before
2000, it includes a NAT. Like modems I've had since 2003, it has
integrated wifi.

Most people I know are not techies - they get one box from the telco /
cableco and just use it. FWIW, most telcos and cablecos will even help
you setup a few laptops/desktops as part of the install.

That's typical for DSL and cable modem installations in the US, and has
been for many years now.

FWIW, people don't buy these things from Amazon or anywhere else
directly in the US - they come free with 1-2 yrs of service.

Joe

---

From: Mark Baugher <[email-masked]>
Date: Mon, 10 Aug 2009 09:55:08 -0700

> Further, I don't see why social controls are useful when a trivial

I expect that you will need policy for any such mechanism - if for
no other reason to allow the user to shut it off when desired.  That's
what is non-trivial on an unmanaged network.  There's not much that's
simply on a home network in my experience.

Mark

> iEYEARECAAYFAkqAKzoACgkQE5f5cImnZruDrgCeKhwSE1AEUyKh55Dc/CCaU8gr
> 0moAoNMagcrG8dRvPuUXZQl7hqZJi0r8
> =7HuG

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2009 10:33:22 -0700

Mark Baugher wrote:
...
>> simply on a home network in my experience.

Users already have many similar things - DHCP, NAT, SSID default to
announce, etc. - "on" by default, and they allow the user to shut it off
or alter the configuration.

This is no different. It's really not a huge leap. It just needs to be
included in the requirements, and defaulted to "ON" like most of these
other things.

Joe

---

From: Mark Baugher <[email-masked]>
Date: Mon, 10 Aug 2009 12:03:14 -0700

> or alter the configuration.

Duplicate DHCP servers and double-NATs are a huge problem for vendors of
home networking equipment when the unskilled user needs to shut it off.
The user may need to shut it "off" when upgrading to a new 802.11N AP
and attaching it to an existing home gateway/router/NAT, for example.
Experience has shown that a majority of home users cannot do that
without making a service call to the vendor's 800 number or hiring
GeekSquad or some other service to reconfigure the network.  The call to
the vendor typically costs the vendor tens of dollars, often for a  
device
that sells for under $50.  GeekSquad, Firedog, etc. costs the non-
professional user about $150 or so.

It should make us more sensitive to HCI in the home when considering new
features that get exposed to users.  Some HCI folks are very hot on  
social
controls and other innovations for this very reason.

That's the point I am trying to make.  Not that there is anything that  
is
particularly complicated in your proposal.  Practically every config  
knob
on the home network has a cost associated with it, often a large cost.

Mark

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2009 12:16:28 -0700

Hi, Mark,

> and attaching it to an existing home gateway/router/NAT, for example.  

I've seen this sort of thing done lots of places and it works fine.

For any default service, the user *may* need to shut it off, but frankly
fair-sharing is far less intrusive than services that are already
defaulted-on, e.g., NAT, SSID-announce, wifi channel selection, etc.

...
> That's the point I am trying to make.  Not that there is anything that is
> particularly complicated in your proposal.  Practically every config knob 

The cost of what I'm suggesting needs to be compared to the context of
other costs. "fair sharing" does cost CPU and buffer memory, but the
benefit -- esp. to naiive users -- is large. As a configuration
addition, it's in the decimal points compared to most home gateway
capabilities.

- ---

My concern is that home gateways often get used in ways that aren't what
most people think is typical. Kids show up with devices that just
connect. Devices exchange large files without explicit user invocation.
Large groups of devices come and go frequently.

Current home gateways fail on two main points right now:
	1) a single user can swamp the pipe
	(e.g., updating their facebook page, or doing
	a bittorrent xfer without knowing it)

	2) flux in the set of users, or large sets of users,
	can bring DHCP to its knees

We saw this when we deployed Tethernet (www.isi.edu/tethernet), a
home-gateway style device that has additional features. Even when it
operated as a regular home gateway - even with a ethernet uplink - we
found that having fair sharing ON and having a reasonably robust DHCP
server was useful. We used it to support conferences (Infocom, Sigcomm),
groups of several dozen demos (DARPA PI meetings, DISCEX conference, NSF
meetings), and various other large meetings at hotels and in homes.

None if this is hard, but existing home gateways fall flat on these
points, and it's worth (a) noting and (b) avoiding.

Joe