[bmwg] RFC 8239 buffering testing results

[Yoshiaki Itou]

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[Jacob Rapp]

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org> on behalf of Yoshiaki Itou <***@toyo.co.jp>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org" <***@ietf.org>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[MORTON, ALFRED C (AL)]

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp>; ***@ietf.org
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[Yoshiaki Itou]

Hello Morton-san, Jacob-san and all,

Thank you for your detail explanation.

In order to more accurately measure the number of frames buffered in the DUT, I tried a method(PAUSE) in which the frame does not flow to the Rx side during frame transmission.
Could you have any comment for this results?

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com>
Sent: Wednesday, July 18, 2018 2:20 AM
To: Jacob Rapp <***@vmware.com>; Yoshiaki Itou <***@toyo.co.jp>; ***@ietf.org
Subject: RE: [bmwg] RFC 8239 buffering testing results

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[MORTON, ALFRED C (AL)]

Hi Yoshiaki,

I’m sorry for the long delay to reply!
Your message was in a very long ToDo list...

Your Pause method, described in the later slides
of your power-point deck, looks very interesting
and appears to be effective. It looks as though you
conducted some testing successfully, too!

I would like to hear what other folks in BMWG think
about your new method. Perhaps we can discuss it
during our session at IETF-103 in Bangkok. It appears
this would be a useful addition to RFC 8239.

regards,
Al
(as a participant)



From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Tuesday, July 24, 2018 7:53 AM
To: MORTON, ALFRED C (AL) <***@research.att.com>; Jacob Rapp <***@vmware.com>; ***@ietf.org
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san, Jacob-san and all,

Thank you for your detail explanation.

In order to more accurately measure the number of frames buffered in the DUT, I tried a method(PAUSE) in which the frame does not flow to the Rx side during frame transmission.
Could you have any comment for this results?

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Wednesday, July 18, 2018 2:20 AM
To: Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[Yoshiaki Itou]

Hello Morton-san,

Thank you for your interest in Pause method.
I am pleased that you are discussing this method at the IETF-103 meeting.

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com>
Sent: Sunday, October 21, 2018 1:10 AM
To: Yoshiaki Itou <***@toyo.co.jp>; Jacob Rapp <***@vmware.com>; ***@ietf.org
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hi Yoshiaki,

I’m sorry for the long delay to reply!
Your message was in a very long ToDo list...

Your Pause method, described in the later slides
of your power-point deck, looks very interesting
and appears to be effective. It looks as though you
conducted some testing successfully, too!

I would like to hear what other folks in BMWG think
about your new method. Perhaps we can discuss it
during our session at IETF-103 in Bangkok. It appears
this would be a useful addition to RFC 8239.

regards,
Al
(as a participant)



From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Tuesday, July 24, 2018 7:53 AM
To: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san, Jacob-san and all,

Thank you for your detail explanation.

In order to more accurately measure the number of frames buffered in the DUT, I tried a method(PAUSE) in which the frame does not flow to the Rx side during frame transmission.
Could you have any comment for this results?

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Wednesday, July 18, 2018 2:20 AM
To: Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[MORTON, ALFRED C (AL)]

Hi Yoshiaki,

We have placed your topic on the BMWG agenda:
https://datatracker.ietf.org/meeting/103/agenda.html#2018-11-08-080000

If you can join us remotely, that would be great!
We are meeting in a convenient time-zone...

regards,
Al
bmwg co-chair


From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Sunday, October 21, 2018 9:50 PM
To: MORTON, ALFRED C (AL) <***@research.att.com>; Jacob Rapp <***@vmware.com>; ***@ietf.org
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san,

Thank you for your interest in Pause method.
I am pleased that you are discussing this method at the IETF-103 meeting.

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Sunday, October 21, 2018 1:10 AM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hi Yoshiaki,

I’m sorry for the long delay to reply!
Your message was in a very long ToDo list...

Your Pause method, described in the later slides
of your power-point deck, looks very interesting
and appears to be effective. It looks as though you
conducted some testing successfully, too!

I would like to hear what other folks in BMWG think
about your new method. Perhaps we can discuss it
during our session at IETF-103 in Bangkok. It appears
this would be a useful addition to RFC 8239.

regards,
Al
(as a participant)



From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Tuesday, July 24, 2018 7:53 AM
To: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san, Jacob-san and all,

Thank you for your detail explanation.

In order to more accurately measure the number of frames buffered in the DUT, I tried a method(PAUSE) in which the frame does not flow to the Rx side during frame transmission.
Could you have any comment for this results?

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Wednesday, July 18, 2018 2:20 AM
To: Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation

[Yoshiaki Itou]

Hello Morton-san,

Thank you for inviting me to the meeting.
Unfortunately I am not convenient for the day and can not join the conference.
I am pleased if you invite me next time.

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com>
Sent: Tuesday, November 06, 2018 7:36 AM
To: Yoshiaki Itou <***@toyo.co.jp>; Jacob Rapp <***@vmware.com>; ***@ietf.org
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hi Yoshiaki,

We have placed your topic on the BMWG agenda:
https://datatracker.ietf.org/meeting/103/agenda.html#2018-11-08-080000

If you can join us remotely, that would be great!
We are meeting in a convenient time-zone...

regards,
Al
bmwg co-chair


From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Sunday, October 21, 2018 9:50 PM
To: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san,

Thank you for your interest in Pause method.
I am pleased that you are discussing this method at the IETF-103 meeting.

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Sunday, October 21, 2018 1:10 AM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hi Yoshiaki,

I’m sorry for the long delay to reply!
Your message was in a very long ToDo list...

Your Pause method, described in the later slides
of your power-point deck, looks very interesting
and appears to be effective. It looks as though you
conducted some testing successfully, too!

I would like to hear what other folks in BMWG think
about your new method. Perhaps we can discuss it
during our session at IETF-103 in Bangkok. It appears
this would be a useful addition to RFC 8239.

regards,
Al
(as a participant)



From: Yoshiaki Itou [mailto:***@toyo.co.jp]
Sent: Tuesday, July 24, 2018 7:53 AM
To: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>; Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Hello Morton-san, Jacob-san and all,

Thank you for your detail explanation.

In order to more accurately measure the number of frames buffered in the DUT, I tried a method(PAUSE) in which the frame does not flow to the Rx side during frame transmission.
Could you have any comment for this results?

Best Regards,
Yoshiaki Itou

From: MORTON, ALFRED C (AL) <***@research.att.com<mailto:***@research.att.com>>
Sent: Wednesday, July 18, 2018 2:20 AM
To: Jacob Rapp <***@vmware.com<mailto:***@vmware.com>>; Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [bmwg] RFC 8239 buffering testing results

Thanks for replying on this thread Jacob.

Incidentally, I added the Section 3 Scope paragraph
delineating the RFC 8239 methods out-of-scope
*after* Yoshiaki and I exchanged several messages.

Al

From: bmwg [mailto:bmwg-***@ietf.org] On Behalf Of Jacob Rapp
Sent: Tuesday, July 17, 2018 12:11 PM
To: Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [bmwg] RFC 8239 buffering testing results

Thanks for reaching out.
Over the years of using these tests myself, I find many different switch architectures may measure differently, but this is expected. The tests themselves were designed to test the actual buffer available for use under various combination of oversubscribing ports, which your test results are reporting. For example, some switches have dedicated buffer for every 4 ports, so if you are testing across the boundaries of these various buffer chips, you may see some “interesting results”. Another example would be when a switch goes from cut-through to store-and-forward operation after a given frame size (we cover this in a different section). Another example would be a switch architecture that uses ingress buffering vs. egress buffering. “Interesting results” are also valid results and the goal of these tests were to flush out the “interesting results” so when evaluating different DUTs you have the complete story vs. what a data sheet will claim on buffer size.

As for the draft-morton-bmwg-b2b-frame-02, it has a different goal and specifically calls out : “Section 3 of [RFC8239] describes buffer size testing for physical
networking devices in a Data Center. The [RFC8239] methods measure
buffer latency directly with traffic on multiple ingress ports that
overload an egress port on the Device Under Test (DUT), and are not
subject to the revised calculations presented in this memo.”

Thanks,
--
Jacob

From: bmwg <bmwg-***@ietf.org<mailto:bmwg-***@ietf.org>> on behalf of Yoshiaki Itou <***@toyo.co.jp<mailto:***@toyo.co.jp>>
Date: Tuesday, July 3, 2018 at 2:06 AM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [bmwg] RFC 8239 buffering testing results

Hello BMWG,

I have measured buffer size of a DUT using RFC 8239 buffering testing. (Please see the attached)
It seems packet-by-packet latency measurement method is a more precise.
However, the increase in latency due to multiple physical ports may not be linearly proportional therefore further improvement is necessary I think.
Could you have any comment for this results?

I am going to measure buffer size of some switches.
Then I would like to have the comparison between draft-morton-bmwg-b2b-frame-02 and RFC 8239.

Best Regards,
Yoshiaki Itou/TOYO Corporation