Subject: Re: [gaia] draft-irtf-gaia-alternative-network-deployments. Mitar review, question #10 Traffic management

From: "Jose Saldana" <[email-masked]>
Date: Wed, 13 Apr 2016 10:33:34 +0200

Hi,

> Section 7.2.1, traffic management when sharing network resources
> 
> It is interesting that so many people believe that there have to be some
special
> prioritization done for sharers to be able to use APs.
> But it is not necessary true. Often people connecting to open AP nodes
will be much
> further away from the AP than the sharer. So often just this distance
already
> influences that the users of open network are prioritized less (they have
higher
> packet loss, lower bitrate, which is also good to limit the lowest allowed
bitrate).

I don't know if we should talk about this effect in the draft. I have just
slightly modified the text (see below).

> 
> In community networks is also pretty common to run the network itself on
different
> frequencies than the APs. Some first generation mesh networks ran
everything
> (backbone over ad-hoc) and client-serving APs on the same channel, but
with 5
> GHz spectrum and cheap dual-band devices this is often separated now.

I think this is interesting. Do you have any reference or example to support
this statement?

This is the current version of the section:

7.2.1.  Traffic Management when sharing network resources

   When network resources are shared (as e.g. in the networks explained
   in Section 5.4), special care has to be taken with the management of
   the traffic at upper layers.  From a crowdshared perspective, and
   considering just regular TCP connections during the critical sharing
   time, the Access Point offering the service is likely to be the
   bottleneck of the connection.

   This is the main concern of sharers, having several implications.  In
   some cases, an adequate Active Queue Management (AQM) mechanism that
   implements a Lower-than-best-effort (LBE) [RFC6297] policy for the
   user is used to protect the sharer.  Achieving LBE behavior requires
   the appropriate tuning of the well known mechanisms such as Explicit
   Congestion Notification (ECN) [RFC3168], or Random Early Detection
   (RED) [RFC2309], or other more recent AQM mechanisms such as
   Controlled Delay (CoDel) and [I-D.ietf-aqm-codel] PIE (Proportional
   Integral controller Enhanced) [I-D.ietf-aqm-pie] that aid low
   latency.

Best regards,

Jose

---

From: Mitar <[email-masked]>
Date: Wed, 13 Apr 2016 03:42:40 -0700

Hi!

> I think this is interesting. Do you have any reference or example to support

Hm, this is so common that I am unsure how to reference this. See
diagrams here for an example:

https://sudoroom.org/wiki/Mesh/Diagrams

Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m