Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion

From: Debby Stopp <[email-masked]>
Date: Tue, 4 Mar 2003 08:52:39 -0800

Mon, 11 Nov 2002 , Fred Baker stated that:
"A congested interface is one for which the queuing delay is measurably 
non-zero, and as a result causes issues for applications running over the
connected internet fabric. It is hard to meaningfully discuss without
bringing the effects on the applications into the discussion."

W/out the 'Lossful' modifier as suggested by Kevin, the term definition for
'Forwarding Congestion":
          "Packet Loss, not increased Delay, is the metric to indicate
          the condition of Forwarding Congestion.  Packet Loss is a
          deterministic indicator of Forwarding Congestion."

is, at best, inaccurate.

- Debby Stopp

> -----Original Message-----
> From: Kevin Dubray [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 12:06 PM
> To: [email-masked]
> Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion
> 
> 
> Do you all agree w/ Jerry's assessment?  The short answer is
> in the last paragraph :-)
> 
> -Kevin
> 
> -------- Original Message --------
> Subject: RE: [bmwg] dsmterm-05 - Forwarding Congestion
> Date: Mon, 3 Mar 2003 11:10:08 -0800
> From: "Perser, Jerry" <[email-masked]>
> To: "'Kevin Dubray'" <[email-masked]>
> CC: "David Newman (E-mail)" <[email-masked]>,   
> "Scott Poretsky 
> (E-mail)" <[email-masked]>,   Shobha Erramilli	 
> <[email-masked]>,   Sumit Khurana <[email-masked]>
> 
>  > But why the reticence to call the term "Lossful Forwarding
>  > Congestion."  And why not call out the lossful attribute
>  > out explicitly in the definition?
>  >
>  > See: http://www.ietf.org/proceedings/02nov/152.htm
>  >
>  >
>  > -Kevin
>  >
> 
> The focus on Congestion is centered around Traffic Control 
> Mechanisms.  By
> externally observing the DUT/SUT ability to forward packets, it can be
> determined whether Traffic Control Mechanisms are active.
> 
> Active and Enabled are two different things.  At low OLOAD, 
> the Traffic
> Control Mechanisms may be enabled, but not effecting the forwarding of
> packets.  Stating it a different way, enabling and disabling 
> the Traffic
> Control Mechanisms will have no externally observable affects.
> 
> Going back to Traffic Control Mechanisms, what are their 
> purpose?  On a per
> hop bases, Traffic Control Mechanisms use some type of intelligence to
> modify packet streams by either delaying the forwarding 
> process or by not
> forwarding select packets.
> 
> The purpose of the I-D is to benchmark the Traffic Control Mechanisms'
> intelligence on a per hop behavior.
> 
> Another point is that RFC1242 and RFC2432 do not call out 
> their lossful
> attribute out explicitly in the definition.  Why not call it 
> Mixed Class
> Zero-loss Throughput?  I have seen reports that have 
> Throughput numbers with
> a loss < 0.01%.  Looking the industry reports, there are 
> Throughput numbers
> and there are Zero-loss Throughput numbers.  I agree the 
> precedence set by
> RFC1242 and RFC2432.
> 
> Last point I would like to make is the notion of "lossless forwarding
> congestion".  If there is lossful, is there also lossless?  
> The answer is
> no.  By dropping the lossful/lossless notion from the 
> definition does not
> change the meaning.
> 
> Jerry.
> 
> ___________________________________________________________
> Jerry Perser                         Spirent Communications
> Director of Test Methodology         SmartBits Division
> Phone: 818.676.2320                  26750 Agoura Road
> Lab:   818.676.2337                  Calabasas, CA, 91302
> Cell:  818.292.6457                  Corp:  818.676.2300
> 
>  
> 
> 
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "David Newman" <[email-masked]>
Date: Tue, 4 Mar 2003 09:36:17 -0800

>           deterministic indicator of Forwarding Congestion."

This is a curious assertion. Let's invert it and see if it still stands up.

Under what conditions would packet loss NOT be a deterministic indicator of
Forwarding Congestion?

dn

ps. The backstory here, for those new to this draft, is that we have opted
for loss as a congestion indicator rather than delay or other metrics
because it is deterministic.

As noted in the ID, increased latency or jitter also may indicate congestion
(in fact, we point to other references that discuss this). The problem with
applying these other metrics here is that they are not deterministic: We
can't say, for example, that a latency increase of X percent will always
indicates the presence of congestion in all cases. There's just no
one-size-fits-all answer, the way there is with loss.

---

From: "David Newman" <[email-masked]>
Date: Tue, 4 Mar 2003 09:36:17 -0800

dn

---

From: David Newman <[email-masked]>
Date: Wed, 5 Mar 2003 19:19:39 -0800 (PST)

> i probably shouldn't hop in the middle here but
> i was skimming mail really fast and i just didn't
> want you to forget about wireless since this
> is the case where you can have loss without
> congestion. of course,  you might want to restrict 
> your document to wired environments to save yourself 
> a lot of headaches but you probably should state this
> is what you are doing.  (skimming the intro to this 
> document didn't seem to indicate what environment 
> this is applicable to)

Interesting issue! While we hadn't specifically considered the wireless
case, we believe the dsterm definitions apply just as well as they do
copper, fiber, piano wire, and the like.

Frame loss over wireless media is orthogonal to the dsterm definition of 
Forwarding Congestion. This is because we're L2-agnostic. 

Wireless frame loss is an L1-L2 event, while the dsterm draft deals only 
with good ol' L3 IP packets. If we offer an IP packet to a DUT/SUT, and 
the DUT/SUT then fails to forward that packet, we can say that the channel 
capacity of the DUT/SUT has been diminished and forwarding congestion 
exists. This is true regardless of link layer or physical medium.

The objective here is to characterize the performance impact of DSCP 
markings, and not to characterize various link layers.

dn

---

From: David Newman <[email-masked]>
Date: Wed, 5 Mar 2003 19:19:39 -0800 (PST)

dn

---

From: David Newman <[email-masked]>
Date: Thu, 6 Mar 2003 09:01:14 -0800 (PST)

On Thu, 6 Mar 2003, Barbara Denny wrote:

> I sent David some more info but maybe I should
> at least mention to the group that this kind of
> loss will look the same to IP.  You lost a packet.
> At IP, how will you know if it was due to congestion
> or a problem at the link layer due to interference,
> etc? Are you requiring that lower layers notify
> IP a packet gets dropped due to buffer or queue
> limits being exhausted?

Not at all. One of OSI's few redeeming features was layer separation --
one variable at a time is a very good thing indeed.

Let's begin by agreeing that loss induced by events at other layers occurs
all the time, and some of these events could affect the sole variable
under observation here -- the DS field in the IP header. Examples include
LOF in Sonet, backoff algorithm timeouts in half-duplex Ethernet, and RF
issues in wireless.

If I understand your question correctly, it is essentially "aren't these 
cases where loss exists without congestion?" and of course the answer is 
yes. 

Still, this issue is orthogonal to the definition at hand. Let's look at 
the definition of forwarding congestion again:

"A condition in which one or more egress interfaces are offered more
packets than are forwarded."

In the cases above, the egress interfaces are offered too FEW packets,
not too many. Given this underfeeding, we would expect the egress
interfaces to be able to forward all packets without loss.

My statement was that loss on the egress interfaces ALWAYS indicates
forwarding congestion. I don't believe anything we've discussed here
contradicts that statement. I could be wrong. If I've missed something
please let me know -- especially if there is a case we've missed where 
loss on egress != forwarding congestion. Thanks.

dn

ps. By the way, the issue of extraneous variables isn't addressed in other
bmwg documents either. I could test a switch or router and get throughput
of 0 bit/s by unplugging a cable, yet still conform to 2889 or 2544.  On
the general question of whether we should make all efforts to factor out
extraneous variables like this, I think we're in complete agreement.

---

From: David Newman <[email-masked]>
Date: Thu, 6 Mar 2003 09:01:14 -0800 (PST)

dn

---

From: Barbara Denny <[email-masked]>
Date: Thu, 6 Mar 2003 09:15:18 -0800 (PST)

Maybe we will end up agreeing that we disagree.
Your definition is very broad but if your criteria
is forwarding, how do you know whether the lower
layers even attempted to forward or not at the IP
layer? How do you know you are offering too few 
packets??? How do you perform such checks?  You might
be giving definitions but if you can't do anything
with them I am not sure how much that helps.

barbara

> extraneous variables like this, I think we're in

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Barbara Denny <[email-masked]>
Date: Tue, 4 Mar 2003 18:13:26 -0800 (PST)

hi,

barbara

--- David Newman <[email-masked]> wrote:
> 
> > W/out the 'Lossful' modifier as suggested by
> Kevin, the term
> > definition for
> > 'Forwarding Congestion":

---

From: Barbara Denny <[email-masked]>
Date: Thu, 6 Mar 2003 08:14:02 -0800 (PST)

Hi,

barbara

---

From: Barbara Denny <[email-masked]>
Date: Thu, 6 Mar 2003 08:14:02 -0800 (PST)

Hi,

barbara

---

From: Barbara Denny <[email-masked]>
Date: Thu, 6 Mar 2003 09:15:18 -0800 (PST)

barbara

---

From: Barbara Denny <[email-masked]>
Date: Tue, 4 Mar 2003 18:13:26 -0800 (PST)

hi,

barbara