From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DA4AA3B29E for ; Mon, 10 Jul 2023 18:49:51 -0400 (EDT) Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-565f3881cbeso3932806eaf.2 for ; Mon, 10 Jul 2023 15:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1689029391; x=1691621391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6buXLGfE2C2824oYNs89T6NKzpqwpI2m1fV8Qs/h+4A=; b=PMz7QrlzQQPtEouwPCreTpeyrZZ7CkArqSpMvgLuqB0AcHyQ5tYMXwB+C7ZLcEQfDQ M3Bb02DgvpKELOPD0IGS6TrazjkXPUEjOelGkr7it5m7UpV7PCztH0zTAZaeKCKfHibC vpsdZIOOuS+f+RPmlQ0+LoDQ0j1I3RUBSa0p4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689029391; x=1691621391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6buXLGfE2C2824oYNs89T6NKzpqwpI2m1fV8Qs/h+4A=; b=Wec81MYexJx3XUs9T1ya0qXHJvmEQKjmi1WUTIz5xREUsumbTQmZUiITtqFLTuOZuA bS3Yeg3ZCpv+KMlZfDhRqMH2nkOqorU6DfnkxAoFPpBOwCsIDBcpHQhQVxsn05/E1ytW fy9Nl0p4l05gQFArFzP01NFfCr6CR3ZDAf9L3j2gqFy82pjUIBjtXS6OsAELKIVhzIME e56CvHh5CovhF4YhKNQwS00PF2foGMw9xLOyIHbrNqGkVL3Wmi/5rzR0nGEjhMSRv+6f +0KFxu3lZUh7JGslHOna7CglSIgc4yjeXiOxoW8/t6RUYf/zo8ruercdt+D5Y9l6v/uB kfCw== X-Gm-Message-State: ABy/qLYHfUNS16PtTztUQQhQSamcwmQ+LCKsbN8gP5X88RHxw8C6qh9M WVhJM73mk2CjxgdPf1O6tebZIZfRh5JUyDEQ99zu4x/L7FtV406HLgFzcrH4q7UO9n7FMi4W2vJ fZ3E3Am7vimTfShpgLcv8CAeMxLDM8l0ABJWjC2GGdg== X-Google-Smtp-Source: APBJJlHPNpQgCKNQFBMC5gtp83nKkzNrh8YwBJVNtY7SnhXLc8XvSf4YQZ+dVkyzpH2jj928qySCf9CHwVhhjK/H+PM= X-Received: by 2002:a4a:dfd9:0:b0:566:8bc8:af2 with SMTP id p25-20020a4adfd9000000b005668bc80af2mr7449099ood.4.1689029390830; Mon, 10 Jul 2023 15:49:50 -0700 (PDT) MIME-Version: 1.0 References: <29385648-o20s-nn8q-2p3s-900sn8606857@ynat.uz> In-Reply-To: <29385648-o20s-nn8q-2p3s-900sn8606857@ynat.uz> From: Bob McMahon Date: Mon, 10 Jul 2023 15:49:38 -0700 Message-ID: To: David Lang Cc: Aaron Wood , Make-Wifi-fast Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e27726060029cc90" Subject: Re: [Make-wifi-fast] I used to dream of a single wifi cpu, memory, and I/O X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2023 22:49:52 -0000 --000000000000e27726060029cc90 Content-Type: multipart/alternative; boundary="000000000000db3f17060029cca2" --000000000000db3f17060029cca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, The proposal with FiWi is to use pt2pt radio paths and spatial separation, free space path loss is an advantage. Stop blasting energy to thousands of square feet, raising the noise floor for no good reasons. I think of it like irrigation sprinklers or led task lighting or electric circuits. We think radios & spectrum as scarce and that assumption is going away quickly. A current WiFi die can hold 100s of CMOS radios and not sure the PHYs (it's somethign I need to check.) The front ends are tricky but th= ose are going up too. There are currently 3 FEs per AP as an example and power and space is going down per every iteration. There is no reason to send energy more than 29' as that's the distance per fire code that a human has to be from a working smoke detector. and in many cities, one can't sell a house without a hard-wired, battery backed up, and inter connected smoke detectors. Might as well put in 2.5Gb/s per spatial stream at 30' RRHs too, at less than 2-3 watts each including the fiber runs. Time to simplify the geography problem. The AP/STA power imbalance is a major design flaw as bad as bufferbloat. Every standard iteration is effectively engineering bloat. I think we're at a point to reassess and simplify everywhere and change the Titanic's direction. Bob On Mon, Jul 10, 2023 at 2:29=E2=80=AFPM David Lang wrote: > you can't just treat wifi as any other transport and have things work > well. > There is too much overhead in sending packets to any destination. Every > other > transport has effectively zero cost to send a packet to A a packet to B > and then > another packet to A. In wifi, you can send hundreds (if not thousands) of > packets to A in the time that it will take you to send a packet to B. As = a > result, you need to queue things per destination in ways that you don't > for > anything else. > > To see how this works, look at the time that you wait to see if the > channel is > used, plus the time needed to transmit the packet header (at a low > bitrate), and > then the time needed to send the actual data (at a high bitrate) > > see how much actual data you could send to one station in the time that i= t > would > take to send two 64 byte packets to two different stations (ignoring > MU-MIMO for > the moment) > > Also, as a practical matter, under most conditions, almost all your > traffic is > going to be wifi <-> wired, very little is wifi <-> wifi (IoT could have > changed > this, but in practice, IoT is IoT <-> cloud <-> user rather than IoT <-> > user) > > David Lang > > > On Mon, 10 Jul 2023, Bob McMahon via Make-wifi-fast wrote: > > > Date: Mon, 10 Jul 2023 13:47:32 -0700 > > From: Bob McMahon via Make-wifi-fast < > make-wifi-fast@lists.bufferbloat.net> > > Reply-To: Bob McMahon > > To: Aaron Wood > > Cc: Make-Wifi-fast > > Subject: Re: [Make-wifi-fast] I used to dream of a single wifi cpu, > memory, > > and I/O > > > > I think of it as a micro translational bridge, i.e. get 802.11 to 802.3 > to > > standard forwarding silicon (though some call it a "skinny" AP.) The "A= P > > split" is between managing MAC/frame things and MAC/PHY things. Try to > > minimize the PHY knobs so the RRH can self-manage what's not been prese= t > by > > the installer. Remove the sw config stuff on the RRH too as it just add= s > > OPEX costs for limited benefit. > > > > Others see it as "bluetooth p2p" model applied to WiFi, but radio > pairings > > at low latency, low power and high throughputs - though this mental mod= el > > has some flaws too. > > > > I think the EAP architecture is woefully broken. "Centralizing the > > controllers" of distribution management isn't the same as *eliminating = & > > mitigating the need to manage complex distributed things. *Linux > computers > > are complex, distributed things and don't belong in homes unless the ho= me > > is owned by a network and sys admin ;) > > > > The closest models seem to be ECPRI used by 5G towers or the distribute= d > > access architecture (DAA) of HFC. > > > > FiWi will blow those out of the water by my judgment - though those are > OSP > > things and FiWi will start as an inside plant thing. We just have to > > figure out how to motivate humans as engineers & marketing experts to > start > > moving in this direction. It seems like a no brainer that consumers wil= l > > want to show off their "fiber" - inside plant, future proof, life suppo= rt > > capable, resilient to failures, & something that increases the property > or > > asset value of their primary investment. Maybe FTTH shouldn't be market= ed > > as "Fiber to the Home" but "Fiber through the Home" with no more wires > for > > comm anywhere? > > > > Bob > > > > > > > > > > On Mon, Jul 10, 2023 at 12:02=E2=80=AFPM Aaron Wood = wrote: > > > >> > >> > >> On Sun, Jul 9, 2023 at 10:40=E2=80=AFPM Bob McMahon via Make-wifi-fast= < > >> make-wifi-fast@lists.bufferbloat.net> wrote: > >> > >>> I wonder if treating WiFi like a transceiver is the better approach, > >>> separating "the computer abstraction" from the remote radio head. > >>> > >>> Then it's a RF Front End(s) / CMOS Radios / PHY(s) / 802.11 MAC(s) > >>> (lower) / 802.3 PAM4 / 100G SERDES / 4 1x25G VCSELs. Pluggable like a= n > SFP. > >>> > >>> The virtualized APs could support at least 10 and maybe 100s of these > via > >>> merchant switching silicon and could be kilometers away. The MACs low= er > >>> could be simplified to dual queue a la L4S. No need for 4 AC queues p= er > >>> MAC. Might be able to throw away 802.11 retries too and let the upper > >>> layers handle it. > >>> > >> > >> Isn't this how the commercial APs that use a combined > >> backhaul/control-plane operate? > >> > >> I've often wanted to use something like OpenVSwitch to combine all the > >> layer-2 broadcast domains without actually making them a single > broadcast > >> domain (central ARP responder/router, multicast-to-singlecast > conversion, > >> mDNS routing instead of always using broadcasts, etc). I know that we > were > >> looking at that with CeroWRT, early on, using routing between separate > >> subnets, but that required a bunch of proxies that never seemed to > really > >> work as well as I wanted (or I wasn't very good at getting them set up > >> correctly). I think we're maybe in a better place for that now. > >> > >> Given that wifi stations must associate with APs, there's so much > >> knowledgeable state that can be centrally (and distributedly) cached a= nd > >> then used to move a bunch of broadcast traffic to single-cast. With t= he > >> huge difference in encoding rates between broadcast and singlecast > traffic, > >> especially as the number of STAs increases, it seems like it would be > very > >> beneficial. > >> > >> And if you were in the 1:1 AP<->STA situation that has floated across > this > >> list a few times (I do find the micro-AP idea fascinating), then all > >> "broadcast" traffic should hopefully become limited-transmit-power > >> single-cast, with minimal use of spectrum (both in terms of time and > >> physical space). > >> > >> One issue that I've seen with many APs in the same space, is that many > >> client stations are very aggressive enumerators of the available APs, > much > >> to the detriment of the operation of the system. I've seen clients Do= S > all > >> the available spectrum with wildcard probe requests and their response= s, > >> which sound like exactly the sort problems seen with ARP in very dense > >> server racks that the vswitch and central ARP server model was meant t= o > >> solve: have a single "best" response instead of flooding the network > with > >> responses (or requests, in the ARP case). > >> > >> May be a good time to simplify. > >>> > >> > >> It seems like perhaps a little more hierarchy/coordination could resul= t > in > >> more simple operation at scale. > >> > >> > >>> > >>> Bob > >>> > >>> On Fri, Jul 7, 2023 at 2:25=E2=80=AFPM Dave Taht via Make-wifi-fast < > >>> make-wifi-fast@lists.bufferbloat.net> wrote: > >>> > >>>> preferably using some sort of async circuitry for minimum interferen= ce > >>>> and power consumption. I figured, oh, 256MB would be more than enoug= h > >>>> for a 10Gbit router. > >>>> > >>>> Instead, we can now layer 64GB on die. > >>>> > >>>> > https://blocksandfiles.com/2023/07/05/3d-stacked-dram-and-processor-cube/ > >>>> > >>>> -- > >>>> Podcast: > >>>> > https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/ > >>>> Dave T=C3=A4ht CSO, LibreQos > >>>> _______________________________________________ > >>>> Make-wifi-fast mailing list > >>>> Make-wifi-fast@lists.bufferbloat.net > >>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast > >>> > >>> > >>> This electronic communication and the information and any files > >>> transmitted with it, or attached to it, are confidential and are > intended > >>> solely for the use of the individual or entity to whom it is addresse= d > and > >>> may contain information that is confidential, legally privileged, > protected > >>> by privacy laws, or otherwise restricted from disclosure to anyone > else. If > >>> you are not the intended recipient or the person responsible for > delivering > >>> the e-mail to the intended recipient, you are hereby notified that an= y > use, > >>> copying, distributing, dissemination, forwarding, printing, or copyin= g > of > >>> this e-mail is strictly prohibited. If you received this e-mail in > error, > >>> please return the e-mail to the sender, delete it from your computer, > and > >>> destroy any printed copy of it. > >>> _______________________________________________ > >>> Make-wifi-fast mailing list > >>> Make-wifi-fast@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast > >> > >> > > > >_______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --000000000000db3f17060029cca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

The proposal with FiWi is to use pt2pt ra= dio paths and spatial separation,=C2=A0free space path loss is an advantage= . Stop blasting energy to thousands of square feet, raising the noise floor= for no good reasons. I think of it like irrigation sprinklers or led task = lighting or electric circuits. We think=C2=A0radios & spectrum as scarc= e and that assumption is going away quickly. A current WiFi die can hold 10= 0s of CMOS radios and not sure the PHYs (it's somethign=C2=A0I need to = check.) The front ends are tricky but those are going up too. There are currently 3 FEs per AP as an examp= le and power and space is going down per every iteration. There is no reaso= n to send energy more than 29' as that's the distance per fire code= =C2=A0that a human has to be from a working smoke detector. and in many cit= ies, one can't sell a house without a hard-wired, battery backed up, an= d inter connected smoke detectors.=C2=A0 Might as well put in 2.5Gb/s per s= patial stream at 30' RRHs too, at less than 2-3 watts each including th= e fiber runs.

Time to simplify=C2=A0the geography problem. The AP/ST= A power imbalance is a major design flaw as bad as bufferbloat. Every stand= ard iteration is effectively engineering bloat. I think we're at a poin= t to reassess and simplify everywhere and change the Titanic's directio= n.

Bob=C2=A0

On Mon, Jul 10, 2023 at 2:29=E2=80=AFPM David Lang <<= a href=3D"mailto:david@lang.hm">david@lang.hm> wrote:
you can't just treat wifi = as any other transport and have things work well.
There is too much overhead in sending packets to any destination. Every oth= er
transport has effectively zero cost to send a packet to A a packet to B and= then
another packet to A. In wifi, you can send hundreds (if not thousands) of <= br> packets to A in the time that it will take you to send a packet to B. As a =
result, you need to queue things per destination in ways that you don't= for
anything else.

To see how this works, look at the time that you wait to see if the channel= is
used, plus the time needed to transmit the packet header (at a low bitrate)= , and
then the time needed to send the actual data (at a high bitrate)

see how much actual data you could send to one station in the time that it = would
take to send two 64 byte packets to two different stations (ignoring MU-MIM= O for
the moment)

Also, as a practical matter, under most conditions, almost all your traffic= is
going to be wifi <-> wired, very little is wifi <-> wifi (IoT c= ould have changed
this, but in practice, IoT is IoT <-> cloud <-> user rather tha= n IoT <-> user)

David Lang


On Mon, 10 Jul 2023, Bob McMahon via Make-wifi-fast wrote:

> Date: Mon, 10 Jul 2023 13:47:32 -0700
> From: Bob McMahon via Make-wifi-fast <make-wifi-fast@lists.bufferblo= at.net>
> Reply-To: Bob McMahon <bob.mcmahon@broadcom.com>
> To: Aaron Wood <woody77@gmail.com>
> Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
> Subject: Re: [Make-wifi-fast] I used to dream of a single wifi cpu, me= mory,
>=C2=A0 =C2=A0 =C2=A0and I/O
>
> I think of it as a micro translational bridge, i.e. get 802.11 to 802.= 3 to
> standard forwarding silicon (though some call it a "skinny" = AP.) The "AP
> split" is between managing MAC/frame things and MAC/PHY things. T= ry to
> minimize the PHY knobs so the RRH can self-manage what's not been = preset by
> the installer. Remove the sw config stuff on the RRH too as it just ad= ds
> OPEX costs for limited benefit.
>
> Others see it as "bluetooth p2p" model applied to WiFi,=C2= =A0 but radio pairings
> at low latency, low power and high throughputs - though this mental mo= del
> has some flaws too.
>
> I think the EAP architecture is woefully broken. "Centralizing th= e
> controllers" of distribution management isn't the same as *el= iminating &
> mitigating the need to manage complex distributed things.=C2=A0 *Linux= computers
> are complex, distributed things and don't belong in homes unless t= he home
> is owned by a network and sys admin ;)
>
> The closest models seem to be ECPRI used by 5G towers or the distribut= ed
> access architecture (DAA) of HFC.
>
> FiWi will blow those out of the water by my judgment - though those ar= e OSP
> things and FiWi will start as an inside plant thing.=C2=A0 We just hav= e to
> figure out how to motivate humans as engineers & marketing experts= to start
> moving in this direction. It seems like a no brainer that consumers wi= ll
> want to show off their "fiber" - inside plant, future proof,= life support
> capable, resilient to failures, & something that increases the pro= perty or
> asset value of their primary investment. Maybe FTTH shouldn't be m= arketed
> as "Fiber to the Home" but "Fiber through the Home"= ; with no more wires for
> comm anywhere?
>
> Bob
>
>
>
>
> On Mon, Jul 10, 2023 at 12:02=E2=80=AFPM Aaron Wood <woody77@gmail.com> wrote: >
>>
>>
>> On Sun, Jul 9, 2023 at 10:40=E2=80=AFPM Bob McMahon via Make-wifi-= fast <
>> make-wifi-fast@lists.bufferbloat.net> wrote:
>>
>>> I wonder if treating WiFi like a transceiver is the better app= roach,
>>> separating "the computer abstraction" from the remot= e radio head.
>>>
>>> Then it's a RF Front End(s) / CMOS Radios / PHY(s) / 802.1= 1 MAC(s)
>>> (lower) / 802.3 PAM4 / 100G SERDES / 4 1x25G VCSELs. Pluggable= like an SFP.
>>>
>>> The virtualized APs could support at least 10 and maybe 100s o= f these via
>>> merchant switching silicon and could be kilometers away. The M= ACs lower
>>> could be simplified to dual queue a la L4S. No need for 4 AC q= ueues per
>>> MAC. Might be able to throw away 802.11 retries too and let th= e upper
>>> layers handle it.
>>>
>>
>> Isn't this how the commercial APs that use a combined
>> backhaul/control-plane operate?
>>
>> I've often wanted to use something like OpenVSwitch to combine= all the
>> layer-2 broadcast domains without actually making them a single br= oadcast
>> domain (central ARP responder/router, multicast-to-singlecast conv= ersion,
>> mDNS routing instead of always using broadcasts, etc).=C2=A0 I kno= w that we were
>> looking at that with CeroWRT, early on, using routing between sepa= rate
>> subnets, but that required a bunch of proxies that never seemed to= really
>> work as well as I wanted (or I wasn't very good at getting the= m set up
>> correctly).=C2=A0 I think we're maybe in a better place for th= at now.
>>
>> Given that wifi stations must associate with APs, there's so m= uch
>> knowledgeable state that can be centrally (and distributedly) cach= ed and
>> then used to move a bunch of broadcast traffic to single-cast.=C2= =A0 With the
>> huge difference in encoding rates between broadcast and singlecast= traffic,
>> especially as the number of STAs increases, it seems like it would= be very
>> beneficial.
>>
>> And if you were in the 1:1 AP<->STA situation that has float= ed across this
>> list a few times (I do find the micro-AP idea fascinating), then a= ll
>> "broadcast" traffic should hopefully become limited-tran= smit-power
>> single-cast, with minimal use of spectrum (both in terms of time a= nd
>> physical space).
>>
>> One issue that I've seen with many APs in the same space, is t= hat many
>> client stations are very aggressive enumerators of the available A= Ps, much
>> to the detriment of the operation of the system.=C2=A0 I've se= en clients DoS all
>> the available spectrum with wildcard probe requests and their resp= onses,
>> which sound like exactly the sort problems seen with ARP in very d= ense
>> server racks that the vswitch and central ARP server model was mea= nt to
>> solve:=C2=A0 have a single "best" response instead of fl= ooding the network with
>> responses (or requests, in the ARP case).
>>
>> May be a good time to simplify.
>>>
>>
>> It seems like perhaps a little more hierarchy/coordination could r= esult in
>> more simple operation at scale.
>>
>>
>>>
>>> Bob
>>>
>>> On Fri, Jul 7, 2023 at 2:25=E2=80=AFPM Dave Taht via Make-wifi= -fast <
>>> make-wifi-fast@lists.bufferbloat.net> wrote:
>>>
>>>> preferably using some sort of async circuitry for minimum = interference
>>>> and power consumption. I figured, oh, 256MB would be more = than enough
>>>> for a 10Gbit router.
>>>>
>>>> Instead, we can now layer 64GB on die.
>>>>
>>>> https://bl= ocksandfiles.com/2023/07/05/3d-stacked-dram-and-processor-cube/
>>>>
>>>> --
>>>> Podcast:
>>>> https://ww= w.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
>>>> Dave T=C3=A4ht CSO, LibreQos
>>>> _______________________________________________
>>>> Make-wifi-fast mailing list
>>>> Make-wifi-fast@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/= listinfo/make-wifi-fast
>>>
>>>
>>> This electronic communication and the information and any file= s
>>> transmitted with it, or attached to it, are confidential and a= re intended
>>> solely for the use of the individual or entity to whom it is a= ddressed and
>>> may contain information that is confidential, legally privileg= ed, protected
>>> by privacy laws, or otherwise restricted from disclosure to an= yone else. If
>>> you are not the intended recipient or the person responsible f= or delivering
>>> the e-mail to the intended recipient, you are hereby notified = that any use,
>>> copying, distributing, dissemination, forwarding, printing, or= copying of
>>> this e-mail is strictly prohibited. If you received this e-mai= l in error,
>>> please return the e-mail to the sender, delete it from your co= mputer, and
>>> destroy any printed copy of it.
>>> _______________________________________________
>>> Make-wifi-fast mailing list
>>> Make-wifi-fast@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/list= info/make-wifi-fast
>>
>>
>
>_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --000000000000db3f17060029cca2-- --000000000000e27726060029cc90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQagYJKoZIhvcNAQcCoIIQWzCCEFcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3BMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBUkwggQxoAMCAQICDDGs4Qlq5OZK9mcDzTANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAxMzMzNDFaFw0yNTA5MTAxMzMzNDFaMIGM MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFDASBgNVBAMTC0JvYiBNY01haG9uMScwJQYJKoZIhvcNAQkB Fhhib2IubWNtYWhvbkBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBfX3nsBFRdO26im8lhOadVadRmV/YWK+U9OoGlTE+2MDsjJwO5p/Q6iaTUropqMRH1E+EIuhe /OU6a3/btrqzARE77RaVSdz5swXt7M4ciN+z44nIEx36UQIlFLsBFa3is/J/QLFhTUFFf0wLJsUO wyja+KvygH/E5TyfeXf5T2Y2wjGZx8jQXZMDmNpfANlEBYDfzCNYcAIQNox8FuPpEpuxWvv7jvxV X5dfkSef9T/DbsDM0PeTVMVyYIQoRSMBIGxVkaqp0MJglvQ2mU4CXcoOGgm6XC8LoLoEvYojXFKC fRgCOT5xeMR10UPSBQIljKwt7fPhpYVY+jTtOclpAgMBAAGjggHZMIIB1TAOBgNVHQ8BAf8EBAMC BaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYBBQUHMAGG NWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwME0G A1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCMGA1UdEQQc MBqBGGJvYi5tY21haG9uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSME GDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUpG/4RP1YQA/iXGens9pIRe7CQxMw DQYJKoZIhvcNAQELBQADggEBACfWLy4qJyCnOa3sl4LEDAMU/gmJ6LbclGE5iR4KanAmlAt92gzN 5lSy/iE+wsRrXiHI7YKFgXX1kVK/RqMiPRrw4hq2j8nxoSi/VFiyS3CsfVMGkbY7HBTlBvla/tH+ +2nJprlXbJyz1GdvoJAeam5RvTWotcCGAjZmMa3U3zMkszgXN849xe3dUK1DauUGiInXEwEdXDcA /0CVjL3EEMj+kNWcLhrSZKwFtxggUyMW3XWRaAeAL9wOtEaXYqlgbtnV0n9FuoV2TNm3h7Mh7rjV I2zM+IZ3DE+XFK7dcPwte33u75QyySNJ3UMZqi25CO85yl8Bmo7aWRm99N7HGnkxggJtMIICaQIB ATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgwxrOEJauTmSvZnA80wDQYJ YIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIIIi9d56yffZVhvf/W8K4eDECjVUYqNccYv9 WUNmYRU2MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDcxMDIy NDk1MVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQCATAN BgkqhkiG9w0BAQEFAASCAQCxPSmKhiyRxKqGZI5sBopz69/gLzS/kEOfjdXIOM1vSis7tzGGy8Hh ESz8GDutv0740RqfooR4aOgHxQXwP76KLokWfTDflCGK/1BUycIrZ8hij+p9qoL+AEQ8LU+6N1r5 Fp7yfBJgnGlRwCCvGmDjm4mTpI+SLOWszgBizOpdKkRjhVDKvg2u8lja1xgYfNiUIFHbN5PWD9m8 HAUEw7ubUZ+OcSGIiqGILyq/YIEBrqXn9bIdeJ9mTSukyA+/1zR7rCiXCuSuB+v2e4mbY2gapiqg IyhVw3z3ieK4sycL9S1mOInvbPzwUKsnsyS8uGNRpufb/FCnJmyKL58qaQ1P --000000000000e27726060029cc90--