Is this capturing all the IoT traffic from around the house, or just what this machine sends and receives?
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 28, 2021 4:05 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Power saving estimates from 802.3av
I use a Linux machine, since that allows me to capture all fields (including VLAN information) and control many more aspects of the capture (e.g., capturing frames with incorrect FCS, fragmented frames, etc.), so there is a difference there. I had to disable three parameters: TCP segmentation, segmentation offload, and receive offload, and now it seems that the capture is performed correctly. No more 1500+ B frames anymore, since the OS receives all segments separately, without the NIC assembling them for CPU offload.
I will re-start the trace tonight around 8 pm and share it again at 8 am tomorrow, giving 12 hours' long window into the whole capture. I will see if I can export smaller pcap excluding packet details, so that you have access to raw data for analysis
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, July 28, 2021 2:49 PM
To: mxhajduczenia@xxxxxxxxx
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Power saving estimates from 802.3av
Marek,
I just run Wireshark with all the default settings on my office system for 15 minutes and only captured sizes between 42 and 1514 bytes. On the web somewhere it says that WS does not capture FCS and padding, which exactly corresponds to the numbers I got. While the Wireshark can reassemble TCP segments, I don’t think it does that by default. There must be something different in your settings.
Glen
From: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 28, 2021 11:18 AM
To: 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Power saving estimates from 802.3av
These are the stats frame size
As far as I know, Wireshark does some reassembly and this might be skewing the frame sizes. I will disable it next time when exporting frame information
However, I may need to go into the laptop I am using for capture purposes and disable NIC offload. That seems to affect the captured packet sizes whereby multiple frames may be lumped together when handed off to the OS layer. I will perform the necessary changes when I get back home today and run the capture overnight again.
As far as timestamps are concerned, based on documentation of libcap, tshark / wireshark use start of packet as a reference point.
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, July 28, 2021 11:53 AM
To: mxhajduczenia@xxxxxxxxx
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Power saving estimates from 802.3av
Marek,
This is great. It is interesting that upstream is only 3% of the total frame count.
Can you check in your setup what is reported as packet length? There are about 1.6K packets with the length between 60 and 63 bytes. On the large side, there are 180 packets with sizes above jumbo frame, from 11270 to the largest 32123 bytes. Are these IP packet lengths? Do you have L2 frame lengths in the pcap?
To find out the interval *between* frames, frame lengths are needed in addition to timestamps. Also, I don’t remember what is the captured timestamp in wireshark – is this the beginning of a packet or the end after FCS is checked? Do you know?
Thanks,
Glen
From: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 28, 2021 6:33 AM
To: 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Power saving estimates from 802.3av
Glen,
Here is the result for last night (9pm – 7am) with 1 second interval. Local time is used for reference.
I sanitized the data and it is available in Excel format for offline analysis: https://drive.google.com/file/d/1lyi2UPZh7xcqdUJyul-mYRX3YV2An9FB/view?usp=sharing. The file is too big to share directly via email so I am sharing it via GDrive. I have the raw pcap file as well, should it be needed. The capture was done at the input interface into my edge firewall, so it contains all Internet traffic before anything gets filtered.
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Tuesday, July 27, 2021 8:21 PM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Cc: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] Power saving estimates from 802.3av
Marek,
IOT or not is not so important. What is interesting is what the traffic looks like when nobody is actively using the Internet, like in the middle of the night.
(Sent from Samsung Galaxy far, far away, where typos are normal)
On Tue, Jul 27, 2021, 6:04 PM Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> wrote:
Glen,
I have separate VLANs for different traffic types, so I should be able to separate IOT from any other traffic types.
I should be able to provide a full resolution graph of packet size vs arrival times, no issues there.
Marek
On Tue, Jul 27, 2021 at 6:42 PM Glen Kramer <glen.kramer@xxxxxxxxxxxx> wrote:
A few more relevant presentations:
https://www.ieee802.org/3/av/public/2008_11/3av_0811_hajduczenia_2.pdf
https://www.ieee802.org/3/av/public/2008_11/3av_0811_hirth_2.pdf
Marek,
Thank you for the offer to capture 24hr data. It would be most interesting to see a distribution of time between successive frames (separately for upstream/downstream). I think just the timestamps and packet sizes are all we need.
Glen
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Tuesday, July 27, 2021 4:49 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [1904.4 TF] Power saving estimates from 802.3av
These are two presentations that have numbers in them:
- https://www.ieee802.org/3/av/public/2008_09/3av_0809_mandin_4.pdf
- https://www.ieee802.org/3/av/public/2008_09/3av_0809_otaka_1.pdf
Regards
Marek
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1