Slides on MLEF/MLPP

The slides I used in the tsvwg meeting today are at
     ftp://ftpeng.cisco.com/fred/mlpp/MLEF+MLPP.pdf
     ftp://ftpeng.cisco.com/fred/mlpp/MLEF+MLPP.ppt

The internet drafts I mentioned are:
     http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlef-concerns-01.txt
     http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt

HTML versions of those same documents (which I personally find easier to 
read) are at:
     ftp://ftpeng.cisco.com/fred/mlpp/mlef-harmful.html
     ftp://ftpeng.cisco.com/fred/mlpp/mlpp-that-works.html

draft-baker-diffserv-basic-classes-02.txt

the draft was just presented and it was agreed that it become a working 
group item (i think pending review by "volunteers" having done work with 
diff-serv?).

in taking the devil's advocate position, I'm curious as to the response
of the authors to those that would object to the draft because it seems 
to be counter to the original diff-serv architecture tenet that 
code-points should not be "tied" to applications.  Does this represent a
shift in that thinking?  And perhaps more importantly, will the IESG reject
the effort on this basis?   this latter item would be nice to know so that
the group and authors don't hit a road block down the road.  I recall 
strong discussions on this subject at the Tokyo-IETF, but I never heard
a final consensus on the matter.

also, at that same meeting, Fred and another co-author worked on a draft 
that discussed the potential for an ingress code-point triggering a 
specific egress code-point -- a kind of asymetric phb marking (I'm not
sure I articulated this well).  does the diffserv-basic-classes draft 
cause problems with this asymetric marking approach

-ken

ps, my apologies for not speaking up at the meeting...its the usual 
lame excuse of massive jet lag 

Re: draft-baker-diffserv-basic-classes-02.txt

At 04:43 PM 03/01/04, Ken Carlberg wrote:
>in taking the devil's advocate position, I'm curious as to the response of 
>the authors to those that would object to the draft because it seems to be 
>counter to the original diff-serv architecture tenet that code-points 
>should not be "tied" to applications.

I thought that was the wrong position at the time, and I think so now. 
Consider, if you will, the question of how one handles (this from the slide 
Kwok showed, which is from a service provider customer, or the DISA class 
proposal. Bottom line, there are very few uses of diff-serv technology that 
work well as a service in a sense divorced from the application.

For example, I am asked by any number of edge networks and ISPs how to 
identify peer-2-peer traffic, whether to shut it down, manage it, or turn 
it into a service. There are various possible ways; none of them are "look 
for the user to be asking for a service which is 'move lots of stuff from 
here to there'". What they wind up looking for is a long-lived session that 
generates a lot of traffic. They often do this by positioning a policer 
that accepts traffic at a high rate for a short interval, but starts 
marking traffic differently if the rate continues. This traffic may be 
treated as more-drop-eligible, may be dropped entirely at an upstream 
provider's point, may be charged for in a different manner, or etc. 
Increasingly, the ISPs are telling me that they want to host the p2p server 
as a service and as a result be in control of it. But bottom line, they are 
worried about a class of applications that do something specific to their 
network - usually in a manner that costs them money and needs to have 
either a way to reduce it or to charge for it. This traffic differs 
immensely from HTTP, SMTP, and such, even though they share the fundamental 
characteristic of being elastic. So simply saying "well, it goes in the AF 
service" isn't adequate. It needs to go into a specified instance of the AF 

Re: draft-baker-diffserv-basic-classes-02.txt

 >> in taking the devil's advocate position, I'm curious as to
 >> the response of the authors to those that would object to
 >> the draft because it seems to be counter to the original
 >> diff-serv architecture tenet that code-points should not
 >> be "tied" to applications.
 >
 > I thought that was the wrong position at the time, and I
 > think so now.

I think this draft should move forward. as a indirect benefit,
it will avoid some possible DSCP misconceptions/misuse; as
it suggests a standard DSCP policy configuration in practice.
In multi6 list, Brian pointed to this work, when someone
suggested a MH solution which proposed DSCP usage in a wrong
way. Also, the draft was reviewed, discussed and got positive
response in both ieprep and diffserv-interest list.

 >> I recall strong discussions on this subject at the Tokyo-IETF,
 >> but I never heard a final consensus on the matter.

just for the record:

  from http://www.ietf.org/proceedings/02jul/220.htm

   ...
   Fred Baker presented draft-ietf-ieprep-packet-marking-policy-00.txt

   Van Jacobsen presented a concern for Kathy Nichols, Diffserv co-chair.
   The concern was that the DSCP is intended to identify traffic supported
   by a service, as opposed to traffic of a certain application type. He

NSIS in Emergency Use

Henning:

I wonder if you could do us a favor.

You asked why I didn't mention NSIS, and I commented that I didn't have a 
coded proposed standard implementation that had the set of characteristics 
I needed; I think your thumbnail precis was "it's not cooked yet".

I wonder if you would mind downloading 
ftp://ftpeng.cisco.com/fred/mlpp/mlpp-that-works.html (or 
ftp://ftpeng.cisco.com/fred/mlpp/mlpp-that-works.xml if you prefer it), 
globally replace

	%s/RSVP/NSIS/

and then ask yourself what ceased to make sense (assuming that it made 
sense before). Clearly, any reference to an RSVP-related assumption, 
document, or bit of functionality needs an NSIS counterpart, and such any 
that don't exist or work significantly differently in context are red 
flags. If you would like to take that up with me off-line, I think we might 
wind up with a contribution to NSIS along the lines of "we think something 
that solves this set of issues might be useful."

Fred

RE: Slides on MLEF/MLPP

It would be helpful if the MLEF draft included recommendations on how it
should be used and how it should not be used.  I think we will find
agreement in where it should not be used without CAC.  Specifically, in
draft-baker-tsvwg-mlef-concerns drafts you rely on the congestive
collapse situation for your main argument against MLEF - briefly, this
is where so many calls occupy a link that all or most low priority calls
drop so many packets that they become unusable.  I think everyone agrees
this is bad and anyone implementing MLEF should be made aware of how to
avoid it.

For example, I think everyone can agree that deploying MLEF to police a
link without Capacity Admission Control (CAC) is not a good idea if the
expected offered load greatly exceeds the capacity.  For example, if you
have a 128 Kbps link, and there is a chance that greater than 20, 6 Kbps
calls will traverse it, CAC should be used in addition to MLEF.

It is unhelpful to completely dismiss MLEF because there are clearly
cases where it can be useful.  For example, if one has a requirement to
maintain at least 5 high priority calls at a quality level of "good" and
to provide as many as possible low priority calls at a level of "fair",
MLEF can be used to increase the aggregate amount of calls versus the
situation where all calls have to meet the higher requirements of the
high priority calls.  This is trading quality for quantity in some cases
and whether this is good or bad will depend on the requirements of a
given situation.  Yes, more bandwidth would solve all this, but there
are some places (ad hoc wireless networks are one example) where you
just don't have more bandwidth and you have to be creative with what you
have.

Completely eliminating MLEF is not a good idea because

Re: draft-baker-diffserv-basic-classes-02.txt

Ken Carlberg wrote:

> the draft was just presented and it was agreed that it become a working 
> group item (i think pending review by "volunteers" having done work with 
> diff-serv?).

AFAIK, from talking with Allison afterwards, what was agreed was only 
that a group of people would look at it further.

The hum was mild, to say the least. And repeated goading was required to 
elicit 2 of the 3 requested volunteers to review the document, out of a 
standing-room only room.

Given the fact that the IETF rarely sees an ID that won't be adopted by 
-some- WG, the lack of enthusiasm was, IMO, deafening. I took it as a 
resounding "NO".

While I appreciate that the IETF may have a 'vested interest' in playing 
in this arena, the community (in the room at least) wasn't very 
enthusiastic at all.

Joe

RE: draft-baker-diffserv-basic-classes-02.txt

> 
> 
>  >> in taking the devil's advocate position, I'm curious as to
>  >> the response of the authors to those that would object to
>  >> the draft because it seems to be counter to the original
>  >> diff-serv architecture tenet that code-points should not
>  >> be "tied" to applications.
>  >
>  > I thought that was the wrong position at the time, and I
>  > think so now.
> 
> I think this draft should move forward. as a indirect benefit,
> it will avoid some possible DSCP misconceptions/misuse; as
> it suggests a standard DSCP policy configuration in practice.
> In multi6 list, Brian pointed to this work, when someone
> suggested a MH solution which proposed DSCP usage in a wrong
> way. Also, the draft was reviewed, discussed and got positive
> response in both ieprep and diffserv-interest list.

I also think this draft should move forward. We are in the process of formulating QoS requirements for
Mobile Broadband Wireless Access (IEEE 802.20) and much of the stuff specified in the draft helps as a reference.

Branislav

Re: draft-baker-diffserv-basic-classes-02.txt

Are you interested in TOEs and related issues (Resend)

Hi,

AT the end of the TSVWG session on Monday, I was trying to see if people
are interested in discussing TOE (TCP offload Engines) from the
prespective of new technology and issues arising out of it. I am
not sure if there are any protocol level issues yet that need to be
discussed under the scope of IETF (tcpm) charter. I just want to
scope out the interest in this area from implementation and integration
in the host OS point of view.

After the meeting, I already met 5-6 people who are interested in
talking about it so we will try and get together sometime wed/thur
after the plenary. If there are more people interested, Ted can
get us a room or figure out a more structured discussion either this
or next IETF meeting.

Please drop me a note with you time preference if you are interested 
and I'll see what we can rig up. A brief background and possible list 
of things to discuss is listed below.

TOE BAckground
--------------

In last couple of years, the number of vendors selling TOE based hardware
has increased significantly and we at SUN have personally talked to 
about 2 dozen such vendors. The claim is that TOE will be necessary for
10Gb NICs and for emerging technologies like iSCSI, RDMA, etc. These
vendors already have first generation h/w available for Windows and Linux
while some of them have moved on to 2nd generation. On Linux, these 
vendors support TOE by overwriting the S/W stack with their own hooks.
With pretty impressive performance and reduction in CPU utilization claims,
even the end users have started asking (atleast SUN) about TOE support.

Some things to discuss
----------------------

1) Are you working with TOEs in any way?
2) Have you faced any issues with TOE. Someof them are:
        - failover. When TOE runs out of resources or doesn't understand
          some options/features.
        - Old (and possibly buggy implementations) burned in ASIC which
          will be hard to upgrade as new modifications are made to TCP
          (even if they are 2-3 every year).
        - End to End correctness issues like TOE acking a packet but dying
          before the data is transfered to host memory. Or accepting the
          data to be sent out but dying before the packet hits the wire.
3) Any other issues?

Cheers,
Sunay

--

-- 
Sunay Tripathi
Senior Staff Engineer,
Solaris Kernel Networking,
Sun MicroSystems Inc.

email: sunay <at> eng.sun.com                 Phone: 650-786-6007 (W)