Subject: [Tsvwg] A Review on Diffserv Basic Classes draft

From: Allison Mankin <[email-masked]>
Date: Thu, 05 Aug 2004 10:03:00 -0700

Here's the third of the reviews for the Review-Session on
draft-baker-diffserv-basic-classes-03.txt.  This is the one whose
reviewer definitely can't be here today for the in-person discussants.
(The other reviewer/discussants are David Black, [email-masked],
and Brian Carpenter, [email-masked])

Alan O'Neill
Flarion
[email-masked]
-------------------------------------------------------------
Wg,

As one of the volunteers from Seoul to review this draft, here are
some high-level comments (included below) on the draft.

So firstly the deafening silence to the specific call for volunteer
could be interpreted (amongst others) as the work being targeted at
the wrong wg, wg attendees wanting to avoid a detailed review of a big
detailed draft that was outside of their immediate interest /
expertise, or potentially complete disinterest in the wg through to
complete disinterest in any IETF wg for this work. I personally
believe the work is eminently useful for both vendors and operators,
and also useful for operators and customers, as it helps facilitate an
abstraction/ generalisation for discussing and agreeing requirements
and solutions. I have no view on the appropriate wg for this, but
absolutely believe that the work is both important and timely, and the
presented draft a very big step towards a very useful BCP.

The draft is not, I believe, intended to break the clean separation in
diff-serv between PHBs and DSCPs and between DSCPs and applications. I
was one of the strong proponents for that separation in the diff-serv
wg to ensure that operator degrees of freedom are not standardised
away at some arbitrary point in time, as a result of a narrow view of
what might be required in the future. That separation was however also
not intended to facilitate a DSCP free-for-all per domain, nor a
resulting multi-lateral inter-domain DSCP intent / remarking fog. The
intention was simply to let the market decide via interations between
vendors/operators and customers as to what app/class/DSCP/PHB
combinations make sense in specific domains, and what generalisations
can then be discovered at specific phases of the development of the
DSCP Internet.

All I feel this BCP will do is enable those service classes that exist
today are evolving in real networks to be captured, documented and the
knowledge distributed to enable the accumulated experience to
propagate, and hence to further accelerate comprehension, adoption and
common configuration. The draft just needs to ensure it does not go
beyond 'recommendations' so that we maintain the abstractions, and do
not lose the flexibility for the future evolution of the constrained
set of DSCP values.

I have no problems with the technical contents of the draft and
believe it clearly already represents significant community consensus.

Regards, Alan.

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 5 Aug 2004 21:22:49 +0300 (EEST)

Hi,

I guess my presentation, and the slide was misleading. The draft itself 
should give a better description of the issue of addressing and routing of 
the Path Request.

I'll try to give a short summary here.

When an end host sends a Path message, it knows the party it is making a
reservation with, right? Let's say that end host Ahost with IP address A
wants to make a reservation for a flow towards end host Bhost with IP
address B. Ahost knows Bhost and will be able to set B as the destination
of the Path message.

For a downstream reservation for a flow coming from Bhost, if Ahost knows
B, it doesn't matter whether Ahost sends a Path or a Path Request to
trigger the "proxy" - Ahost will anyway use B as the destination of the
message. The routing infrastructure will get the message to the proxy.

The idea to have a separate message is that it makes the design
clearly separate from standard RSVP. The Path and Path Request messages
are identical in format, just the message type differs. Moreover, the Path
Request is only needed once, for triggering the proxy. Further Path
Requests may not be needed. So, the Path Request does not have as
destination address the proxy's IP address - I guess this was not clear
from my presentation.

The interesting case is, whether Ahost could make a downstream
reservation without knowing the sender? For example, set up a wildcard
reservation for VoIP flows to certain ports regardless of the sender.

In this case, Ahost needs an IP address for the trigger message, what ever
the message type is. This is where, if such a feature is needed, we need
to have some rules on how to address the trigger message. The draft
suggests to use e.g. the address of the default router, which would be
configured by the operator to know where the proxy is, or Ahost could have
the address of the proxy configured automagically. I don't think the
message type matters here, the question is how to address and route the
trigger message.

Thus, in summary, the basic case where Ahost knows Bhost for upstream and 
downstream reservations, there is no need for Ahost to know anything about 
the proxy, except that it is there, somewhere.

I guess the general opinion was that something like this would be a good
thing. NSIS has this, but will not be mature for quite some time.  There
were some comments for and against this spec. I'd like to know if, after
reading the draft (it's not that long), people feel like this should go
forward, or not.

I'll be here in San Diego up to early Saturday morning, if someone wants 
to talk about this some more.

Regards,
Jukka