Subject: [Ieprep] RE:polk-ieprep-flow-model-considerations-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 23 Jan 2003 17:20:48 -0600

At 04:14 PM 1/18/2003 -0600, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:

> > Comments on this ieprep list are appreciated
>
>1/ I really like the draft. Its very crisp and provides a good
>classification of application level data/control plane. I might
>be missing something very basic. But, I fail to understand
>how the draft serves as a point of reference for the WG when
>discussing *if (and which) QoS mechanisms* should be employed
>for each individual (application) protocol packet flow.

I don't want to step in *it* too deep here, but there have been discussions 
that have merged all combinations of Data Plane with the two Control Planes 
as if they are to be treated in the same manner. I thought this short ID 
could serve as educator/reminder of sorts to reduce this occurrence in the 
future.

>My understanding of application-level signaling is that it helps in
>differentiating various applications. The quality of service part
>(network level) will remain the same whether we are going to use
>in-band or out-of-band /receiver-initiated or source-initiated
>signaling.

Taking your statement at face value, I *could* read into it that (for 
example) SIP signaling is to have the same treatment (if there is any in 
the first place) as RTP.

I think few would actually agree with this as a general rule. RTP has 
delay/jitter tolerances that are far  more sensitive to that Protocol's 
normal operation than does SIP or MGCP or MEGACO/H.248 messages.

>An ISP can provide some kind of static provisioning
>(best effort) or network level signaling (RSVP) to support the
>application depending on their service features.

Would a SIP "INVITE" or a MEGACO "ADD" need RSVP to be successfully 
received by its intended destination? But one could argue fairly 
successfully that an RTP stream justifies RSVP usage under many circumstances.

>So, how does your
>draft helps in identifying whether the application has to use
>QoS or not?

I hope it helps demonstrate that there are different flows traversing 
different paths, allowing the reader to know to isolate their efforts on 
any one flow or path at a time - and not group too many of them together.

>Do you mean to say, " Since the draft has classified
>the application level stuff used for ieprep, one can infer whether
>those application require QoS mechanisms based on their known
>delay/jitter requirements."

This is certainly one of several inferences that I would like a reader to 
conclude.

There is at least one more document I want to write as the next logical 
step of this document - which will hopefully target your comment quoted 
just above more directly. I felt this document was required first.

>2/ The draft has not mentioned RTSP and SAP. Is that media-on-demand
>and broadcast applications are not useful for ieprep?

I didn't mention a protocol that hasn't appeared on the list yet, I just 
did a search again to reconfirm that neither SAP or RTSP have yet 
(according to my mail program). I'm sure though that I left a few protocols 
that have been mentioned out, and want feedback to that affect.

I'll look to the group and chairs for guidance as to whether to include 
either or both SAP and RTSP in this document. It certainly wouldn't take 
much, but I also want to be conscious of having the list of protocols 
included not get too large and off track for IEPREP's mission.

Thank you for the feedback

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"

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