Subject: RE: [Ieprep] Re: Summary of IEPREP work and VoIP

From: "Nguyen, An" <[email-masked]>
Date: Fri, 13 Dec 2002 09:32:59 -0500

Ran,

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Friday, December 13, 2002 8:45 AM
To: King, Kimberly S.
Cc: 'ieprep '
Subject: [Ieprep] Re: Summary of IEPREP work and VoIP

>or SIP proxy firewalls or IP routers that are configured to enable 
>CBQ/CoS
>or link-layer QoS mechanisms)

>>  that are enhanced to only setup the highest priority calls
>> over the access link, up to a predetermined maximum influenced by the 
>> speed
>> of the access link, possibly even supporting preemption.

>That phrasing is awkward and ambiguous since the IP-layer still does not
>have the concept of a "call".  Presumably what one meant is something
>more like:

>...that are enhanced to provide preferred forwarding over the access 
>link
>to IP datagrams that are associated with specific authorised 
>emergency-related
>flows, up to some predetermined maximim influenced by the speed of the
>access link.  This preferred forwarding might involve CBQ in routers,
>lower-drop probability for authorised emergency-related IP packets,
>or other mechanisms.  Some such mechanisms might be inside the 
>link-layer,
>rather than in the IP-layer or above.

The wordings should be flexible to give room for folks who want to implement
QoS mechanisms in other layers such as IP and Transport. There are quite a
few ISPs who implement Diff-Serv in IP. In Transport layer I saw a proposal
from one fairly known company (which I don't want to name here) that wanted
to use its proprietary ping and traceroute software to map out the state of
the Internet and route IP traffic to AVAILABLE paths in real time. This way,
packet delay and jitter can be reduced substantially. I am not saying that I
like these TWO better than link-layer QoS. 

In short, my point is we don't want to rule out anything at this EARLY
stage. :-)

An

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 09:47:38 -0500

> like these TWO better than link-layer QoS.

I've been agreeing that there are things one can do intra-domain with 
DiffServ;
DiffServ is an IP-layer function (despite the IETF putting the WG into 
the
"services" portion of the "Transport & Services Area").  There are 
potentials
for intra-domain IP-layer QoS and link-layer QoS.  I don't see how one 
could
do routing stuff above the IP-layer though.

I'd like to understand what stuff can reasonably done inside the 
Transport-layer
in this regard, where the usual definition of Transport-layer would 
include
TCP, SCTP, and UDP (maybe also XTP, but that's got nil deployment).  I 
think
of the transport-layer as including congestion avoidance and control, 
but
NOT path selection.  And I'd call any form of IP routing to be part of 
the
IP-layer.  (If you don't feel comfortable listing company names on an 
IETF
list, maybe you could email me a URL for whatever the public 
documentation
is for this other widget/feature/thing ?)

Maybe we're merely not understanding each other ?  I'm pretty sure that
I don't know what stuff could be put into the transport-layer that could
possibly affect IP routing (or path-selection, which is the same thing).

> In short, my point is we don't want to rule out anything at this EARLY

I'm generally agreeable that we don't want to rule stuff out.