Subject: [bmwg] Minutes for the bmwg session at IETF-69

From: Al Morton <[email-masked]>
Date: Wed, 01 Aug 2007 08:43:34 -0400

Folks,

The draft minutes are here:
http://www3.ietf.org/proceedings/07jul/minutes/bmwg.html

Please send me any corrections, etc.

Thanks to all those who attended for another very productive
meeting.

regards,
Al
bmwg chair

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Al Morton <[email-masked]>
Date: Wed, 01 Aug 2007 08:51:21 -0400

And Thanks to Tom Alexander for Taking Notes!

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Wed, 1 Aug 2007 15:21:49 +0200

Some notes of clarification which I couldn't make due to the
time-pressure because there was presure catch-up 
with the agenda set for the BMWG meeting.

1) Question from the notes:
"Scott wanted to know what was the logic behind 1280 bytes. Jerry Perser
pointed out that there was no logic."

Logic is that for IPv6 this is a special value and we may see many of
this size packets on 
IPv6 Internet, especially when new devices and new services are more and
more available. 
Actually 1280 is the MinMTU for IPv6 and using packets with maximum size
of 1280 avoids 
PMTU discovery by the end-devices.

2) Wrt The current consensus proposal for the recommended set of packet
sizes is:

<>
Ethernet: 64, 128, 256, 512, 1024, 1280, 1518 bytes
SONET: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 
Include a note for the following topics:
	- 47 was chosen as the limit case
	- how to select a minimum frame size to include the signature
field
<>

This corresponds quite well, and these values are well established with
many traffic generators 
and measurement devices. These values have a proven track record through
rfc2544.
>From RFC2544 it can be seen that these values are used and being
consistent tends 
to make sense especially when comparing IPv4 and IPv6 benchmarking
results.

<> relevant snips from RFC2544<>
9.1 Frame sizes to be used on Ethernet
       64, 128, 256, 512, 1024, 1280, 1518
9.2 Frame sizes to be used on 4Mb and 16Mb token ring
       54, 64, 128, 256, 1024, 1518, 2048, 4472
9.3 Frame sizes to be used on FDDI
       54, 64, 128, 256, 1024, 1518, 2048, 4472
<>end<>

Brgds,
G/

-----Original Message-----
From: Al Morton [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 2:44 PM
To: [email-masked]
Subject: [bmwg] Minutes for the bmwg session at IETF-69

Folks,

Thanks to all those who attended for another very productive meeting.

regards,
Al
bmwg chair

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 1 Aug 2007 16:49:09 +0200

> From: Gunter Van de Velde (gvandeve) [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 4:22 PM
> To: Al Morton; [email-masked]
> Subject: RE: [bmwg] Minutes for the bmwg session at IETF-69

> Ethernet: 64, 128, 256, 512, 1024, 1280, 1518 bytes

Sorry for entering probably very late in this discussion. Are not we
missing here the max frame size values of 1522 (VLAN-tagged Ethernet
frames) and 2048 as recently approved by the IEEE 802.3as project
(extended frame size Ethernet)? 

Dan

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Wed, 1 Aug 2007 12:15:54 -0400

Hello Dan,

Thank you for the suggestion! The current text in the draft state the
following regarding Ethernet frame sizes:

"The following frame sizes SHOULD be used for benchmarking over this
media type: 64, 128, 256, 512, 1024, 1280, 1518 bytes.  Tests with jumbo
frames SHOULD be executed. Frame sizes should be selected based on the
values supported by the device under test due to the absence of a common
standard defining the jumbo frame sizes. Examples of common jumbo frame
sizes are: 4096, 8192, 9216 bytes."

Where do you think it would be best to include the 2048 size, in the
first or second category? Considering 802.3as it does make sense to
explicitly list it.

Regarding 1522 size, I would also agree that considering 802.3ac it
makes sense to list it explicitly but instead of 1518. I would like to
make sure there was no specific reason for maintaining 1518. RFC 2544
came out after 802.3ac was approved.

Best Regards,
Chip

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 10:49 AM
To: Gunter Van de Velde (gvandeve); Al Morton; [email-masked]
Subject: RE: [bmwg] Minutes for the bmwg session at IETF-69

> 
> 2) Wrt The current consensus proposal for the recommended set of 
> packet sizes is:
> 
> <>

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 1 Aug 2007 18:29:14 +0200

It may be useful to include all max sizes 1518, 1522, 2048 as covered by
different generations of 802.3 standards. This would allow to identify
implementations that are limited to a previous version of the standard
and point this to the implementer. 

The three common jumbo sizes seem OK to me, based probably on what
vendors did, as jumbo are out of the IEEE standard scope. 

Dan

> From: Chip Popoviciu (cpopovic) [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 7:16 PM
> To: Romascanu, Dan (Dan); Gunter Van de Velde (gvandeve); Al 
> Morton; [email-masked]
> Thank you for the suggestion! The current text in the draft 
> state the following regarding Ethernet frame sizes:
> 
> "The following frame sizes SHOULD be used for benchmarking 
> over this media type: 64, 128, 256, 512, 1024, 1280, 1518 
> bytes.  Tests with jumbo frames SHOULD be executed. Frame 
> sizes should be selected based on the values supported by the 
> device under test due to the absence of a common standard 
> defining the jumbo frame sizes. Examples of common jumbo 
> frame sizes are: 4096, 8192, 9216 bytes."
> 
> Where do you think it would be best to include the 2048 size, 
> in the first or second category? Considering 802.3as it does 
> make sense to explicitly list it.
> 
> Regarding 1522 size, I would also agree that considering 
> 802.3ac it makes sense to list it explicitly but instead of 
> 1518. I would like to make sure there was no specific reason 
> for maintaining 1518. RFC 2544 came out after 802.3ac was approved.
> 
> Best Regards,
> Chip
>

---

From: "Tom Alexander" <[email-masked]>
Date: Wed, 1 Aug 2007 10:43:59 -0700

A minor clarification on the 1280 byte frame size discussion. During the
discussion in Chicago, the issue at hand was not so much the specific use of
a 1280 byte frame size but instead why the frame sizes specified in RFC 2544
were "magic". Jerry's response was to the effect that when they were
originally specified there was nothing "magic" about them at all. There is
no mention of IPv6 in either RFC 2544 or its predecessor (RFC 1944).

RFC 2544 in fact bears this out, in section 9.1 (excerpted below):

	"9.1 Frame sizes to be used on Ethernet

	These sizes include the maximum and minimum frame sizes permitted by
	the Ethernet standard and a selection of sizes between these
extremes
	with a finer granularity for the smaller frame sizes and higher
frame
	rates."

Clearly these specific frame size values were selected on an ad-hoc basis
(but with reasonable justification). For example, the authors of RFC 2544
could have selected 1000 instead of 1024 bytes and it would have made little
difference to the validity of the test results. However, 1024 is a "nice"
number (a power of 2) and might also be relevant to actual traffic
distributions.

I certainly agree, though, that once we have consensus on a set of standard
frame sizes we should continue to use those frame sizes as far as possible,
to ensure that measurements can be compared over the years.

Best regards,

- Tom A.

-----Original Message-----
From: Gunter Van de Velde (gvandeve) [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 6:22 AM
To: Al Morton; [email-masked]
Subject: RE: [bmwg] Minutes for the bmwg session at IETF-69

<>

consistent tends 

Brgds,
G/

-----Original Message-----
From: Al Morton [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 2:44 PM
To: [email-masked]
Subject: [bmwg] Minutes for the bmwg session at IETF-69

Folks,

regards,
Al
bmwg chair

---

From: David Newman <[email-masked]>
Date: Wed, 01 Aug 2007 13:17:46 -0700

On 8/1/07 10:43 AM, Tom Alexander wrote:

> difference to the validity of the test results. 

True. At the same time I believe we should try to compare like with like
wherever possible.

> to ensure that measurements can be compared over the years.

One tidy way of addressing Dan's question would be simply to standardize
on untagged lengths, and then add a section on VLAN testing requiring
the addition of 4 bytes (or 8 or more, if VLAN stacking/QinQ is in use)
to each frame length.

Note that the VLAN tag affects all lengths, not just the 1518-byte case.

dn

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2007 13:23:45 +0200

In-line.

Dan

> From: David Newman [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 11:18 PM
> To: [email-masked]
> Subject: Re: [bmwg] Minutes for the bmwg session at IETF-69
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Clearly these specific frame size values were selected on an ad-hoc 
> > basis (but with reasonable justification). For example, the 
> authors of 
> > RFC 2544 could have selected 1000 instead of 1024 bytes and 
> it would 
> > have made little difference to the validity of the test results.
> 
> True. At the same time I believe we should try to compare 
> like with like wherever possible.
> 
> > I certainly agree, though, that once we have consensus on a set of 
> > standard frame sizes we should continue to use those frame sizes as 
> > far as possible, to ensure that measurements can be 
> compared over the years.
> > 
> 
> One tidy way of addressing Dan's question would be simply to 
> standardize on untagged lengths, and then add a section on 
> VLAN testing requiring the addition of 4 bytes (or 8 or more, 
> if VLAN stacking/QinQ is in use) to each frame length.

Yes, this would be fine. I also agree with the argument made by Tom that
values already covered by 2544 should be kept in the new version, so
that we can compare results of measurements. 

> Note that the VLAN tag affects all lengths, not just the 

Slight correction on this. The 2048 maxlength value adopted by IEEE
802.3as is meant to include all VLAN tagging cases (Q in Q include) +
the IEEE 802.1 header required by IEEE 802.1ae (MACSEC) + some generous
spare for future extensions required by protocols carried by Ethernet

---

From: David Newman <[email-masked]>
Date: Thu, 02 Aug 2007 07:29:36 -0700

> spare for future extensions required by protocols carried by Ethernet

Sorry, I was making the much narrower point that this isn't just an
issue of adding a 1522-byte length to the list, but rather 64->68,
128->132, and so on.

dn

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Fri, 3 Aug 2007 17:32:45 -0400

It seems we have an agreement to include 1522 and 2048 in the main set.
Also add a note that these two frame sizes reflect the evolution of the
802.3 standard to include VLAN tagging.   

I am still not sure if we need to keep 1518. I acknowledge the point
made that it might be good to have all the previously recommended sizes
for data comparison however, I am not convinced it is necessary. We keep
all the sizes in the original set minus this one and the additional 4
bytes should not have a significant impact or lead to dramatic
revelations. I am not sure we need two data points that close to each
other.

Best Regards,
Chip

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Thursday, August 02, 2007 10:30 AM
To: [email-masked]
Subject: Re: [bmwg] Minutes for the bmwg session at IETF-69

On 8/2/07 4:23 AM, Romascanu, Dan (Dan) wrote:

> the IEEE 802.1 header required by IEEE 802.1ae (MACSEC) + some 
> generous spare for future extensions required by protocols carried by 
> Ethernet

dn

---

From: David Newman <[email-masked]>
Date: Fri, 03 Aug 2007 14:46:27 -0700

> It seems we have an agreement to include 1522 and 2048 in the main set.

I do not agree that *any* +4 VLAN length such as 1522 belongs in the
main set. Dan's comment as AD seemed to support my suggestion of having
a separate section for testing with VLANs.

This is also conceptually cleaner; there's one standard set of lengths,
and then this set optionally can be modified for users interested in
VLAN testing. Not everyone uses VLANs, and some folks that do use
multiple VLAN tags. A separate section allows the use of one or more
tags without forcing those lengths on everyone else.

> for data comparison however, I am not convinced it is necessary.

It's not just for comparison with RFC 2544 and 2889 and 3918 results,
though that is very meaningful for anyone trying to compare IPv4 and
IPv6 performance, or to conduct mixed-version tests.

The other issue is that 1518 still is a maximum length for Ethernet, as
given in IEEE 802.3-2002. My understanding (possibly erroneous, and I
hope Dan or someone else will correct me if so) is that 802.3as
maintains the same frame format and data length field as previous versions.

Ergo, a tester not hobbled by QinQ and wrapped in ESP and AH over a GRE
tunnel etc. etc. etc. will still have a maximum length of 1518 bytes.

dn

---

From: "Tom Alexander" <[email-masked]>
Date: Fri, 3 Aug 2007 15:45:12 -0700

My reading of subclauses 3.1, 4.2.7.1 and 4.4 of IEEE Std 802.3-2005
indicates that if a traditional (non-802.3as) Ethernet frame does not
contain a VLAN tag, then it cannot exceed 1518 bytes in size. It is not
required for all Ethernet frames to contain VLAN tags - e.g., those coming
into access rather than trunk ports are usually untagged. For instance some
of the APs that I am testing can't handle untagged frame sizes greater than
1518.

Thus I would think that we still need a 1518 byte frame size to handle the
situation of untagged frames in traditional Ethernet.

Best regards,

- Tom A.

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 2:33 PM
To: David Newman; [email-masked]
Subject: RE: [bmwg] Minutes for the bmwg session at IETF-69

Best Regards,
Chip

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Thursday, August 02, 2007 10:30 AM
To: [email-masked]
Subject: Re: [bmwg] Minutes for the bmwg session at IETF-69

dn

---

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Sat, 4 Aug 2007 11:03:26 -0400

David,

It seems I interpreted Dan's earlier comments differently. Nevertheless,
the points you made below (and Tom completed) are reasonable. So let me
summarize the conclusion of the discussion then:

1) The recommended frame size set stays as is (RFC2544) 
2) Will add a note such as:

"Note: The recommended 1518 bytes frame size represents the maximum size
of an untagged Ethernet frame. According to the IEEE 802.3as standard,
the frame size can be increased up to 2048 bytes to accommodate frame
tags."

This text simply indicates to options available without elaborating on
benchmarking with tagged frames which is outside the scope of the
document. A tester can choose to use VLAN tags and naturally account for
them at all frame sizes (similar to testing with any type of additional
tags or headers). The note simply helps the reader understand the upper
bound options. Please provide comments on the write-up.

Best Regards,
Chip

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 5:46 PM
To: [email-masked]
Subject: Re: [bmwg] Minutes for the bmwg session at IETF-69

> made that it might be good to have all the previously recommended 
> sizes for data comparison however, I am not convinced it is necessary.

The other issue is that 1518 still is a maximum length for Ethernet, as
given in IEEE 802.3-2002. My understanding (possibly erroneous, and I
hope Dan or someone else will correct me if so) is that 802.3as
maintains the same frame format and data length field as previous
versions.

dn

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 5 Aug 2007 11:13:59 +0200

I am fine with the proposed resolution. 

Dan

> Sent: Saturday, August 04, 2007 6:03 PM
> It seems I interpreted Dan's earlier comments differently. 
> Nevertheless, the points you made below (and Tom completed) 
> are reasonable. So let me summarize the conclusion of the 
> discussion then:
> 
> "Note: The recommended 1518 bytes frame size represents the 
> maximum size of an untagged Ethernet frame. According to the 
> IEEE 802.3as standard, the frame size can be increased up to 
> 2048 bytes to accommodate frame tags."
> 
> This text simply indicates to options available without 
> elaborating on benchmarking with tagged frames which is 
> outside the scope of the document. A tester can choose to use 
> VLAN tags and naturally account for them at all frame sizes 
> (similar to testing with any type of additional tags or 
> headers). The note simply helps the reader understand the 
> upper bound options. Please provide comments on the write-up.
> 
> Best Regards,
> Chip
> 
> I do not agree that *any* +4 VLAN length such as 1522 belongs 
> in the main set. Dan's comment as AD seemed to support my 
> suggestion of having a separate section for testing with VLANs.
> 
> This is also conceptually cleaner; there's one standard set 
> of lengths, and then this set optionally can be modified for 
> users interested in VLAN testing. Not everyone uses VLANs, 
> and some folks that do use multiple VLAN tags. A separate 
> section allows the use of one or more tags without forcing 
> those lengths on everyone else.
> 
> It's not just for comparison with RFC 2544 and 2889 and 3918 
> results, though that is very meaningful for anyone trying to 
> compare IPv4 and
> The other issue is that 1518 still is a maximum length for 
> Ethernet, as given in IEEE 802.3-2002. My understanding 
> (possibly erroneous, and I hope Dan or someone else will 
> correct me if so) is that 802.3as maintains the same frame 
> format and data length field as previous versions.
> 
> Ergo, a tester not hobbled by QinQ and wrapped in ESP and AH 
> over a GRE tunnel etc. etc. etc. will still have a maximum 
> length of 1518 bytes.
> 
> dn
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
> 
> iD8DBQFGs6IyyPxGVjntI4IRAgYvAJ41HNucOOri0Zwwr6NIYF257SVo8gCg65ax
> H/Jr/rFo6z6qynE2WAyb/RU=
> =BgKN
> -----END PGP SIGNATURE-----
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 5 Aug 2007 11:26:35 +0200

In line. 

Dan

> Sent: Saturday, August 04, 2007 12:46 AM
> To: [email-masked]

Just for clarification, I prefer to see my comments as contributor
comments at this stage. 

> format and data length field as previous versions.

The latest version of IEEE to be referred should be IEEE 802.3-2005.
IEEE 802.3as incorporates within IEEE 802.3 and extends the maximum
frame size to 2048. This extension is introduced in order to accommodate
various tags (VLANs, Q in Q, MACSEC). 

The proposed resolution which would keep 1518 for compatibility to
previous measurements of untagged frames, and would add 2048 in order to
accommodate tagged frames as per IEEE 802.3as should cover all practical
cases.

---

From: David Newman <[email-masked]>
Date: Sun, 05 Aug 2007 07:11:40 -0700

> I am fine with the proposed resolution. 

same here

dn