Subject: Re: draft-nichols-diff-svc-arch-00.txt

From: Ed Ellesson <[email-masked]>
Date: Tue, 02 Dec 1997 18:11:52 -0500

Gentlemen, 

Ahem, the proposal that Steve Blake and I put together has a code point for
network control traffic that I think would accomodate Tony's requirement?

Please see: 

A Proposal for the Format and Semantics of the TOS Byte and Traffic Class
Byte in IPv4 and IPv6 Headers

http://diffserv.lcs.mit.edu/Drafts/draft-ellesson-tos-00.txt

At 02:53 PM 12/2/97 -0800, Tony Li wrote:
>
>Paul,
>
>   Are you specifically referring to the draft in the subject line, 
>
>Yes.
>
>   Quite frankly, I believe that draft-ferguson-delay-drop-00.txt makes
>   this a no-brainer. 
>
>Agreed.  However, that's a bit encoding for the classification, not an
>entire service architecture.  The Nichols draft proposes a service
>architecture but omits the (IMHO) necessary fast classification of control
>traffic.  
>
>Tony

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 02 Dec 1997 20:47:28 -0500

>http://diffserv.lcs.mit.edu/Drafts/draft-ellesson-tos-00.txt

A couple of comments on draft-ellesson-tos-00.txt, since you
brought it up:

o I'm not really keen on using the IPsec compliance issue as
  a method to ensure compliancy with everything in the universe.
  I'm much more concerned about delivering a real-world diff-serv
  application that can be used today. Philosophical debates on
  whether IPsec is real or not is another issue entirely.

o Again, I remain unconvinced that ECN actually gives us anything
  useful. At least in the short term (and perhaps in the long term).
  In any event, I don't endorse any diff-serv proposal today that
  encourages the explicit use of ECN. I believe that the simple
  delay & drop semantics expressed in draft-ferguson-delay-drop-00.txt
  are sufficient. As an aside, several of us have determined to combine
  drafts after the IETF next week -- namely Juha and I. Perhaps this will
  give more credence to the methods we endorse.

o I think we agree on non-adaptive flow treatment, as well as the methods
  of using a token-bucket on ingress to measure/shape/mark traffic.

o We definitely do *not* agree on bit semantics. This is obviously an
  area of discussion. I believe you have made it much too complex,
  especially in the area of ECN -- I believe this should be excluded,
  at least in the first iteration of a working diff-serv implementation.

o I have a definite appreciation for the RSVP message interworking
  issues, however, I decided not to tackle them in the first iteration
  of my draft. I'm not sure that we should actually try to solve all
  problems at the onset, but rather, discuss them in more detail. This
  will require input from the RSVP and inserv wg's.

I believe this at least gives us some issue to discuss prior to
next week, no?

- paul