Subject: Re: [Ieprep] proposed charter

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Sep 2006 00:35:14 -0500

comments in-line

At 01:21 AM 9/26/2006 -0400, Curtis Villamizar wrote:

>Two people sent me private email pointing to the email message with
>the proposed charter.
>
>http://www1.ietf.org/mail-archive/web/ieprep/current/msg02421.html
>
>Thanks.
>
>Seems mostly reasonable to me.  One paragraph seems open ended and may
>be a source of trouble for other reasons.
>
>   If there is an existing group that can extend a protocol or
>   mechanism, IEPREP will generate only a requirements document for
>   those groups to evaluate. If there is not an existing group that can
>   extend a protocol or mechanism, IEPREP will prepare requirements and
>   discuss the extension of that protocol/mechanism or
>   protocols/mechanisms within IEPREP.
>
>This is a promise to liason with anybody and everbody that intends to
>work in this area and to step back and let that other group do the
>protocol work.

Correct, and this is what IEPREP has been limited to since its creation 
(i.e. it has only been able to do requirements, and no solutions)

>The IESG favors (with good reason) WG charters that
>propose to do work

ah, but IEPREP isn't allowed to *do* anything, only write requirements for 
other WGs to *do* something, and only *if* that WG decides to *do* anything 
with the requirement(s), which may get brushed asside as not interesting, 
or without significant WG interest (from that other WG).

RFC4412 took 6 years to get done due to lack of interest in another WG, yet 
the IEPREP WG could have done the work in 2.

>rather than WG charters that propose to sit back
>and watch the ITU do work in that area.

Well... the intention is to have IEPREP actually be able to extend 
protocols that don't currently have WGs chartered for said protocols, and 
it there are WGs for said protocols - to give those WGs merely the 
requirements.  This paragraph's intent is to state that IEPREP doesn't want 
to step on anyone's toes if a current WG charter elsewhere covers a desired 
piece of protocol work, and actually do the work if it isn't chartered 
anywhere else.

ITU-T is mentioned in a cooperative sense, but IEPREP isn't expecting to 
assign ITU-T work.

>A good example (and closely
>related to this sort of work) where the result coming from the ITU was
>not at all useful is the ITU QoS requirements work in the mid to late
>1990s.  This may be looking too much like more of the same.

<snip>

>Any effort which requires the whole world to agree before getting
>started will never get started.
>
>Curtis
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Sep 2006 23:10:59 -0700

>> started will never get started.

So will any effort which requires the people who care and are  
prepared to implement to write requirements documents, but precludes  
them from actually doing the work in favor of someone else who has to  
be convinced.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 07:22:12 -0400

In message <[email-masked]>
> comments in-line

same here.

> (i.e. it has only been able to do requirements, and no solutions)

This may come from the "requirements first, then solutions" approach
that the IETF has taken where there has been disagreement about what
the requirements are.  I've read all of the IEPREP RFCs and the
requirements are still not nailed down.  For example, it is important
to know how many priority/preemption values there will be and whether
each priority requires three drop preferences as required by an AF
service.

> the IEPREP WG could have done the work in 2.

Lack of interest translates to lack of paying customers.  If a
government or government agency has an urgent need they may need to
cough up research money and later fund a deployment.

It would be interesting to have a report on implementation of RFC4412
and deplyment experience.  Generally things with lots of "interest"
get deployed before the RFC is even reviewed by the IESG.

> ITU-T is mentioned in a cooperative sense, but IEPREP isn't expecting to 

The way the paragraph reads, if ITU is doing something, then IEPREP
should not be doing protocol work in the same area.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 07:41:36 -0400

> them from actually doing the work in favor of someone else who has to  

That didn't parse very well.

You can write all the requirements documents in the IETF you want.
Real work happens when someone is sufficiently interested to fund real
work, meaning create some running code and run it on a real network.

The protocols that move through the process most quickly have an
urgent need and are implemented and often deployed before hitting RFC
status.  The IETF WG then reconciles differences between the initial
implementation and requirements that were either overlooked or
discovered in initial deployment.

"Interest" in something doesn't mean willingness to provide lip
service (write documents).  We have an overabundance of that
throughout the IETF and other standards bodies.

If interoperability is required and for anything of importance in
networking it generally is, then the providers and vendors work
together (in theory at least, though it is obviously an imperfect
process) and make things interoperate.

Insistance on standardization before implementation just results in
bad protocl standards with bells and whistles not needed and missed
real requirements.

Maybe IEPREP already has too many spec writers and not enough
implementors motivated by deployment intentions.

Curtis

ps - If something languishes for 6 years, either there is too little
real interest even if the spec was finally published or in very rare
cases it got implemented and deployed based on a draft and there was
lost interest in a bogged down IETF process.

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 26 Sep 2006 09:27:11 -0400

You seem to be under the misapprehension that RFC 4412 has not been
implemented.

It is being demonstrated at the MultiService Forum's  (MSF ) Global MSF
Interoperability (GMI) 2006 event in October.

Janet

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 12:04:56 -0400

> Interoperability (GMI) 2006 event in October.

Thanks for the info.  Actually I thought it would have been
implemented by now and maybe deployed by VOIP providers.  I'm actually
surprised that its not deployed.  [btw- demonstrated on what?]

Henning Schulzrinne seems to have his head in the real world even
though not everything he's pushed for reach fruition.  I thought he'd
at least provide reference implementations as part of his research as
long as he could get the funding to do so.

Regardless, my statement below still stands.  Just had a private email
exchange in which the topic of unfunded mandates vs sufficiently
funded request for competitive bids sort of came up.  Maybe its just
that the former only brings out the spec writers (and hostility from
the ISPs) and the latter produces a more positive and productive
reaction.

[ no funding no action.  what a surprise.  yes I know that has changed. ]

Curtis

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Sep 2006 10:27:19 -0700

or whether drop priority even makes sense operationally, which it  
doesn't.

On Sep 26, 2006, at 4:22 AM, Curtis Villamizar wrote:

> For example, it is important

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 18:02:58 -0400

> > each priority requires three drop preferences as required by an AF

Fred,

For PSTN voice it doesn't but for elastic real time or elastic bulk
transfer it might.  What you are saying is that AF doesn't make sense.
Maybe it doesn't but if so the diffserv WG wasted a lot of time.
Either that or maybe ETS will never be anything but voice traffic.

Or perhaps you think the network is and always will be massively
overprovisioned.  The telephone network and IP infrastructure in
LA and MS was not overprovisioned after Katrina rolled through and
that was a time when a better ETS service would have been handy.

Curtis

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Sep 2006 15:52:30 -0700

On Sep 26, 2006, at 3:02 PM, Curtis Villamizar wrote:

> transfer it might.

for them, it might but we need to discuss. It's not anywhere near as  
obvious as it might sound. In the end, it's about what kinds of  
guarantees they are asking for. In at least one scenario, the  
relevant folks are asking to be able to download a file of a stated  
size within a stated amount of time. To do that, I need to be able to  
predictably give the preferred traffic class, whatever it is called,  
a stable bandwidth. Drop priority doesn't accomplish that; it only  
accomplishes that the preferred traffic competes more effectively and  
therefore gets a larger subset of the traffic. I can fairly easily  
construct scenarios in which even the preferred traffic gets bombed  
off the link.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 21:03:57 -0400

> construct scenarios in which even the preferred traffic gets bombed  

A decade ago we went through a similar argument (not you and I but the
technical community) regarding the Internet and QoS.  The whole point
of RFC1633 is to explain that you can have an absolute guarentee and
it will incur a given cost or you can have a service that from a
practical standpoint is indistinguishable but relies on an extremely
high statistical expectation of acheiving the same level of service
but at an order of magnitude less cost.

ETS brings up a similar question.  Will the market favor inefficiency
(much greater need to overprovision) for the purpose of an absolute
service guarentee, or will it favor a more efficient use of available
bandwidth but without absolute guarentees.

Even using voice based ETS as an example, consider the following.
When a disaster has occurred and a fraction of available
infrastructure remains operational, is it better to have N disaster
relief audio streams supportable with a 100% expectation of service
quality or is it better to have 10 * N disaster relief audio streams
supportable with 99.9% expectation of the same service quality.
Given that an occasional dropped packet in audio or video is almost
indistinguishable (and radio service is far less than a perfect audio
channel) I think that the latter would be far more useful.

The same for file transfer.  If it takes 10 sec but 0.0% of the time
takes 11 sec, but you can support 10 times as many sessions, then I'd
take the tiny risk and tremendous improvement in multiplexing
efficiency.

This tradeoff may depend on how many sessions are multiplexed on a
given resource, If N is a small integer then chance of collision slow
down increases.  If N is very large then guarenteed and predictive
service asymtotically approach indistinguishable.

But then again, I don't work for a phone company.  :-)

I do agree that if all that the ETS is doing is bridging two PSTN
segments, the multiplexing gain is not possible (its already TDM
traffic) and EF makes perfect sense.

In any case I do think starting with EF service or an alternate
EF-like codepoint for ETS makes sense.  Having this codepoint
recognized across providers may override any multiplexing efficiency
considerations.

Curtis

ps - Am I reopenning a can of worms?

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Tue, 26 Sep 2006 19:21:14 -0500

Folks,

I thought there were no absolute guarantees in life or
telecommunications.   ;-) 

Stuart Goldman

Lucent Technologies

[email-masked]

602 493 8438

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 6:04 PM
To: Fred Baker
Cc: James M. Polk; [email-masked]
Subject: Re: [Ieprep] proposed charter 

Fred Baker writes:

 

efficiency.

considerations.

Curtis

Ieprep mailing list

[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Sep 2006 12:17:18 -0500

>transfer it might.  What you are saying is that AF doesn't make sense.

For voice?

>Maybe it doesn't but if so the diffserv WG wasted a lot of time.

Have you looked at who wrote 2597?

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2006 14:44:06 -0400

In message <[email-masked]>
> >transfer it might.  What you are saying is that AF doesn't make sense.

ETS == voice  ?  That was the question.

We already know that in general: voice != AF

Just confirming that Fred considers ETS to be voice only - at least
for now.  btw - I think that is a valid assumption - at least for now.

> Have you looked at who wrote 2597?

If (ETS == voice) then restricting ETS to EF is not an issue.  See
next sentence quoted below.

If ETS can also be elastic traffic of the type that was intended for
AF but we have declared AF to be not useful for ETS, then it implies
that AF is not useful.  That's all I was try to imply, nothing more.

Personally I think AF is useful that is why I wanted confirmation that
Fred is assuming that ETS is voice only.

> >Either that or maybe ETS will never be anything but voice traffic.

We should be clear about assumptions.  You and Fred seem to be
assuming that ETS == voice, but also seem to be reluctant to say that.

Here are some of my assumptions.  We need to walk first, then run.
The IETF should not assign DSCP codepoints for everyones pet idea.
For now ETS is assumed to be voice.  EF is fine for voice.  A new
codepoint allows traffic to be universally identified as being ETS
related.  That might be good or bad.  ETS may later carry more than
just voice.  If needed the decision to use one codepoint can be
revisited.  There has never been anything stopping a deployment in
which an experimental set of DSCP code points are used, EF-like,
AF-like, or something else.  There is nothing to prevent a ETS
deployment from using the existing AF codepoints.  If the use of
experimental codepoints proves useful, additional ETS codepoints can
be added later.

Curtis

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 27 Sep 2006 11:26:41 -0700

Curtis,

> ETS == voice  ?  That was the question.

The tacit assumptions of many is that this is true.  But it is not now,
and increasingly will not be.

The Marines in Iraq are today using the same network* for voice and for
tactical data.  In the case that was relayed to me recently, 'tactical
data' meant the position report of an IED (roadside bomb) that showed up
on the plot of a deployed patrol.  The data is 'elastic' in the sense
that you used it -- as long as it shows up in time for the patrol
commander to reach properly, that's good enough.  In this particular
case that's exactly what happened; the patrol reacted by changing its
route.  

*right now a good share is two parallel networks.  But the backbone is
increasingly VOIP sharing with other ports over a single backbone, ...
and that's progressing down the food chain.  The obvious payoff is
breaking the one-app == one-radio stovepiping.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Sep 2006 12:05:19 -0700

> for now.  btw - I think that is a valid assumption - at least for now.

depends on which "ETS" you're talking about. In the military space,  
current proposals suggest at least one "preferred elastic" class  
similar to AF for elastic applications as well as preferential real  
time services for voice and video. In the civilian space, unless  
Janet-et-al tell me otherwise, the current discussion is of an  
Internet counterpart for GETS, which is to say that it is about voice.

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 27 Sep 2006 15:10:03 -0400

My understanding (and Martin et al can correct me/clarify):

Current discussion is about voice.
Video conferencing is actively under consideration
Elastic traffic is a long term goal, but not currently being addressed in
any detail.

Janet

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 27 Sep 2006 14:13:16 -0500

Beyond voice, nothing has been defined. 

-----Original Message-----
From: Janet P Gunn [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2006 3:10 PM
To: Fred Baker
Cc: James M. Polk; [email-masked]
Subject: Re: [Ieprep] proposed charter

Current discussion is about voice.
Video conferencing is actively under consideration
Elastic traffic is a long term goal, but not currently being addressed
in
any detail.

Janet

---

From: ken carlberg <[email-masked]>
Date: Wed, 27 Sep 2006 15:30:14 -0400

In the long term, ETS as an umbrella term (and stressing the term  
Service) can be applied to applications other than voice.  in  
rfc-3689 (General Requirements for ETS), we state the following under  
the Problem section (The key item being the first sentence)

    A subsequent problem is to ensure that requirements associated with
    potential support is not focused just on IP telephony applications.
    The I-Am-Alive (IAA) database system is an example of an ETS type
    application used in Japan that supports both signaled and non-
    signaled access by users [10].  It is a distributed database system
    that provides registration, querying, and reply primitives to
    participants during times of an emergency (e.g., an earthquake) so
    that others can make an after-the-event determination about the
    status of a person.  In this case, a separate signaling protocol  
like
    SIP is not always required to establish or maintain a connection.

    Given the case where signaling is optional, requirements and
    subsequent solutions that address these problems must not assume the
    existence of signaling and must be able to support applications that
    only have labels in data packets.  These label(s) may be in various
    places, such as the application or IP header.

the low hanging fruit and the immediate attention for some users/ 
clients of ETS is voice in the context of IP, given that that there  
are deployed systems like GETS in the PSTN world which need to be  
bridged and eventually migrated to the IP world.  But this immediate  
attention shouldn't confuse others into thinking that ETS exclusively  
= voice.

-ken

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Sep 2006 00:00:37 -0400

> Internet counterpart for GETS, which is to say that it is about voice.

In the military space that I've heard about there is no non-military
traffic so plain Ol' EF and AF should do it.  If the military is using
or begins using the commercial Internet as part of their ETS, then
they can request DSCP codepoints for their EF (more than one is never
needed if traffic is policed) and as many AF classes as they need
(within reason).  This would give military and non-military traffic
separate DSCP codepoints to work with.  Again, this might be a "later"
when the military has deployed EF and AF and needs to extend this over
the commercial Internet.  If it is commercial Internet from day one,
they can still use an existing AF class as long as the provider(s)
have one free.  It is very easy to do a DSCP mapping at an AS boundary
and DSCP marked traffic is something exchanged only "among consenting
adults".  Such a mapping would make a smooth transition possible.

Some of the things the military has pushed for either didn't happen or
didn't work.  For example, MARS and NHRP.  It would be premature to
assign codepoints for hypotheticals.

So I think the "just adding one EF codepoint for ETS is OK for now"
assumption still holds with the emphasis on "at least for now".

Curtis