headers
Randy Bush | 3 Apr 2003 07:33

an iesg comment on draft-ietf-ipfix-reqs-09.txt

4.2(4) What about link-layer distinguisher of IP version?

4.3 What about SCTP?

4.4, 4.5, and others:  This document can't say "If the observation point is
located at a foo".  At most, it can say "a foo-capable box MUST" or "a 
box SHOULD do such-and-such so that it can be located at a foo".

4.6 strikes me as dubious for compression.

What about the IPv6 Flow Label as a flow separator?
Permalink | Reply | 0 comments |
headers
Randy Bush | 3 Apr 2003 17:47

an iesg comment on draft-ietf-ipfix-reqs-09.txt

from an iesg reviewer

randy

---

   I would prefer to see the paragraph referencing RFC 2119 in section 2.

   Last paragraph in section 6.3.3 needs to be reworded.

   In section 10.2, an important point is left unsaid.  If the injection of 
IPFIX traffic fool the network provided into thinking that a DOS attack is 
underway, the countermeasures employed by the network provider may actually 
deny service to real customers.

   The appendix needs to be moved up in the document.
Permalink | Reply | 0 comments |
headers
Randy Bush | 3 Apr 2003 18:01

yet another iesg comment on draft-ietf-ipfix-reqs-09.txt

Overall, I like it.  A couple of things jumped out at me, though.
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
         Which bytes of a packet are counted MUST be defined exactly.

     20. multicast replication factor
         the number of outgoing packets originating from a single   
         incoming multicast packet. This is a dynamic property of     
         multicast flows, that may change over time. For unicast flows  
         it has the constant value 1. The computation of the factor MUST
         be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?

Also, at the end of 6.1 it kind of says "Plus other stuff related to inter-AS
routing if you want".  It's already in the MAY section; can't they just
list some concrete items related to inter-AS routing as 27, 28, ...?
I don't think it's useful to say what amounts to "plus anything else that
you might feel like adding that you think is relevant", since that doesn't
encourage different people to make the same choices.
Permalink | Reply | 0 comments |
headers
Epelde Gorka | 4 Apr 2003 17:01
Picon
Picon

Asking for some help


Hi to all,
	     This is Gorka. I'm  working in a project to develop some kind
of benchmarking software to test wireless hardware that is going to be
develop at my company's communications area. I'm looking for a RFC, or some
benchmarking information that is related to the benchmarking of wireless
hardware.

	I would really apreciate any help.

Thank you

_______________________________________________________________________

 	Gorka Epelde					
	Communications area		
 	IKERLAN 					
	Pº J. M. Arizmendiarrieta, 2
 	20500 Arrasate-Mondragón (Gipuzkoa)
 	Tel.:   +34 943 71 24 00 	Fax:    +34 943 79 69 44
 	E-mail: gepelde <at> ikerlan.es  	http:    www.ikerlan.es
_______________________________________________________________________
Permalink | Reply | 0 comments |
headers
Perser, Jerry | 8 Apr 2003 00:57

RE: dsmterm-05 - Forwarding Congestion

Mark,

Please do not post emails in HTML format.  It messes up the archives.
Answers are in-line:

>Yes it is the case. The tester determines the offered load and the shape of
the offered
>load. Thus it is the tester that determines if a DUT/SUT will become
congested. If the
>tester sends a Offered Load of 0 percent then what would cause the
congestion? 

This is a philosophical case.  An Offered Load of 0 percent constitutes zero
packets over the total test duration.  If no packets are offered (zero), no
packets are lost, hence no forwarding congestion.  There is a requirement to
offer one or more packets in order to externally observe traffic control
mechanisms.  In fact, RFC1242, RFC2285, and RFC2432 also have this
requirement of offering one or more packets.

>If the tester offers traffic to system under test and the test encompasses
the complete 
>system then the offered load is the cause for the congestion (see comments
for 
>paragraph 1 ) The fact remains that the test person needs to understand
what he/she is 
>doing ( what a concept ). If for any reason, any port becomes congested it
is still 
>caused by the traffic offered and it makes absolutely zero difference as to
who did 
>what to whom. If you are defining a chain of devices as a SUT then any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perser, Jerry | 8 Apr 2003 02:36

RE: latency - incorrect interprtation?

Sunil,

RFC2544 is an update to RFC1944 that was written before the RFC2119
requirements.

Could this be a sentence that Scott and Jim missed?  I would like to hear
from then either (preferably both) of them on this subject.

Does the absence of RFC2119 reference to section "23. Trial description"
mean that we are free to redefine each and any of the five phases?  Is phase
C optional?  It doesn't say "MUST".

Jerry.

> -----Original Message-----
> From: sunil kalidindi [mailto:kalidindi <at> yahoo.com]
> Sent: Monday, March 24, 2003 11:27 PM
> To: bmwg <at> ietf.org
> Subject: [bmwg] latency - incorrect interprtation?
> 
> 
> I've been reviewing some current drafts in the BMWG
> and noticed that the drafts seem to assume that
> "latency" is only measured at throughput.
> 
> That is a little surprising because my understanding,
> and certainly several others I talked to as well, is
> that latency can be measured at different offered
> loads. There are several valid reasons why you want to
> measure it at various loads.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perser, Jerry | 8 Apr 2003 02:45

RE: WG Last Call: draft-ietf-bmwg-dsmterm-05

Good point.

The I-D references "the end of last binary digit of the Internet Datagram
[RFC791]".  Is this clear enough?

Jerry.

-----Original Message-----
From: Dana Heins [mailto:dheins <at> ixiacom.com]
Sent: Wednesday, March 19, 2003 10:15 AM
To: Bmwg (E-mail)
Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-05

While we're cleaning up the Delay defintion, perhaps there is a more clear
phrasing of the phrase: 'bit of the IP packet'.  Does 'bit' refer to binary
digit or is it slang meaning  a 'piece of the packet'?  Perhaps it would be
more clear with phrases like:

Start of the IP Header (what if it's tunneled?)
Start of packet (but only if qualified IP packet)
-----Original Message-----
From: Debby Stopp [mailto:dstopp <at> ixiacom.com]
Sent: Wednesday, March 19, 2003 9:41 AM
To: Bmwg (E-mail)
Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-05

I have some comments regarding this definition:
     3.2.4 Delay

        Definition:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 8 Apr 2003 03:16
Picon
Favicon

RE: dsmterm-05 - Forwarding Congestion

At 03:57 PM 04/07/2003 -0700, Perser, Jerry wrote:
> >This definition needs to be tabled and reworked., it's a mess.
>
>Where to you work Mark?  I am curious where your expertise lie.  Your email
>address was from Mark E. Robinson [martian <at> cyberwitch.com].  I am trying to
>figure out what the BMWG has to do with Witchcraft.

Comments like "it's a mess" are not helpful,
and prompt other bad behaviors.

This stuff stops here.

Keep it constructive, or keep it off the list.

Al
Permalink | Reply | 25 comments |
headers
Perser, Jerry | 8 Apr 2003 18:42

RE: WG Last Call: draft-ietf-bmwg-dsmterm-05

Dana,

You have a good point.  I was not being sarcastic.  My goal is to make this
I-D as clear as possible.

I am willing to change 'the last bit' to 'the end of last binary digit of
the Internet Datagram [RFC791]'.  

Before I change it, I would like some consensus from the reflector.  Is the
change clearer?  Or is there a more precise way of stating this?

Jerry.

> -----Original Message-----
> From: Dana Heins [mailto:dheins <at> ixiacom.com]
> Sent: Tuesday, April 08, 2003 8:56 AM
> To: 'Perser, Jerry'
> Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-05
> 
> 
> Hi Jerry,
> 
> After I wrote that, I noticed that this phrase 'the last bit' 
> is used in
> many RFC's, so it seems that this is a well understood phrase.  
> 
> -----Original Message-----
> From: Perser, Jerry [mailto:jerry.perser <at> spirentcom.com]
> Sent: Monday, April 07, 2003 5:46 PM
> To: 'Dana Heins'; Bmwg (E-mail)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sunil Kalidindi | 8 Apr 2003 19:03
Favicon

RE: latency - incorrect interprtation?

Jerry,

Certainly, the common interpretation is that "latency" is NOT limited to
measurement at throughput. So yes, it would be useful to get feedback from
them and others on the reflector.

Regards,
- Sunil

-----Original Message-----
From: Perser, Jerry [mailto:jerry.perser <at> spirentcom.com]
Sent: Monday, April 07, 2003 5:37 PM
To: 'sunil kalidindi'; bmwg <at> ietf.org
Subject: RE: [bmwg] latency - incorrect interprtation?

Sunil,

RFC2544 is an update to RFC1944 that was written before the RFC2119
requirements.

Could this be a sentence that Scott and Jim missed?  I would like to hear
from then either (preferably both) of them on this subject.

Does the absence of RFC2119 reference to section "23. Trial description"
mean that we are free to redefine each and any of the five phases?  Is phase
C optional?  It doesn't say "MUST".

Jerry.

> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |

Gmane