I have the same concern with suggestions that we "infer" the priority of
responses from the cached state of the associated request - the issue
being that you have to parse the response, then fetch the state info, to
decide its disposition. The extent to which that is a concern is of
course implementation specific.
In response Jeroen suggested an idea similar to Dean's. He suggested
sending requests (hence, receiving the associated responses) on
different ports, based on priority. You could then, under congestion,
make congestion -related decisions (which could include but are not
necessarily limited to, drop vs. enqueue decisions) based on the port on
which responses are received.
Works for me, as might a diffserv tie-in. I don't know that any
mechanism needs to be mandated, but I think it would be useful to
document the expectation that responses are handled with priority
equivalent to that with which the associated request was handled. I
think wording like that could support also the case that the element
(e.g., proxy) handles all requests with the same priority.
tim
________________________________
From: Janet P Gunn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 2:20 PM
To: Dean Willis
Cc: 'IETF SIP List'
Subject: Re: [Sip] What does draft-polk-sip-rph-in-responses-00
get us? Isthatwhat we want?
--
Dean Willis <[EMAIL PROTECTED]> wrote on 09/26/2007
02:57:35 PM:
> Perhaps. But if you have to receive, enqueue, and parse the
messages
> to find out they have high priority or not, and if that's a
> substantial part of the workload, and NOT forwarding the
low-priority
> responses is going to dramatically increase your workload (due
to
> cascade), then you gain nothing and lose much by using RPH to
> prioritize responses. This needs to be tied to some
lower-layer
> mechanism (like a diffserv marking) that can allow for discard
> without so much parsing.
>
I would like to hear more on this approach.
> --
> Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
