Subject: Re: (ION) QoS

From: "Taisto Qvist" <[email-masked]>
Date: Fri, 2 Apr 1999 09:52:24 +0200

But the applications isn't suppose to talk to nhrp/clip, it only talks
to the ip-stack. So what i was thinking of was, if we assume the app is
capable of asking for QoS via the socket-calls (this is where you doit, 
right?) And the ip-stack also has support for it, which, afaik, most don't 
(yet). Can the ip-stack in its turn request this Qos from the underlying 
clip/nhrp driver. The easiest to think of this is if the client
is using the ip-TOS field, will these diffrent packets be sent down
the same ubr-connection?

> Taisto Qvist wrote:
> > 
> > Hi everyone.
> > 
> > I'm wondering about Clip, and nhrp and "their" support for
> > QoS. Are any endstationimplementations that would/could care about
> > for instance IP-precedence, or anything like that ?
> > So that a more prioritized ip-packet, would cause a "better"
> > vc to be established ?
> > 
> > Which OS:es has current support for clip/nhrp?
> > What kind of vc is established as default ? UBR ? ABR ?
> > 
> > or should i ask this question to another forum ?
> > 
> > Regards
> > Taisto Qvist
> 
> It depends on the kind of application. If the application is able to
> communicate to NHRP about its Qos requirements then a VC must be setup
> accordingly. For IpV4, i think currently that is not possible. Also i
> don;t think there is a great support for Qos in IPv4. So by default a 
UBR
> will be set up by NHRP.
> 
> I think same should be true for CLIP (not sure).
> 
> 
> -Ajay
> 

             \\\|///
           \\  ~ ~  //
            (  @ @  )
  +-------oOOo-(_)-oOOo-------+
  | From: [email-masked]    | 
  | Tel work: 08 720 86 31    |
  | Tel GSM : 0708 142756     |
  +---------oooO-Oooo---------+
            (__) (__)
         PGP Fingerprint
7D04 6E09 EE90 98D4 FE26  9DDA 4C54 4B79 9580 A06D             
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Albert Manfredi" <[email-masked]>
Date: Fri, 2 Apr 1999 10:27:22 -0500

----- Original Message -----
From: Taisto Qvist <[email-masked]>

> But the applications isn't suppose to talk to nhrp/clip,
> it only talks to the ip-stack. So what i was thinking of
> was, if we assume the app is capable of asking for
> QoS via the socket-calls (this is where you doit, right?)
> And the ip-stack also has support for it, which, afaik,
> most don't  (yet). Can the ip-stack in its turn request
> this Qos from the underlying clip/nhrp driver. The
> easiest to think of this is if the client is using the
> ip-TOS field, will these diffrent packets be sent down
> the same ubr-connection?

Somehow, the idea of adding QoS on top of NHRP doesn't work very
well, unless IP also has QoS guarantees available. Or unless you
only consider the most trivial scenario.

In the trivial case, where source and sink devices are ATM-connected
and on the same well-shaped (sort of round) ATM infrastructure, no
big deal. NHRP finds the routed path, the destination NHS sends back
the AESA of the sink, and a direct connection can be established. It
could be VBR, CBR, whatever you like. As long as the routed path
doesn't hop in and out of the well-shaped ATM net to get to the
destination, the QoS demands can very possibly result in PNNI (and
even AINI?) finding a shortcut that is completely unrelated to the
routed path, but who cares. So it's possible in this trivial case to
use the TOS byte to ask for ATM QoS.

In the more general case, though, the NHRP request will hop across
non-ATM segments of the route. This can happen _even if_ the
underlying ATM net is contiguous from source to sink, but has a
weird shape. The AESA of the destination provided by NHRP, along
each ATM segment of the journey, will only be the AESA of a router.
So what QoS guarantees can you get?

If the non-ATM parts of the trip were either RSVP or diff-serv
capable, perhaps some semblance of QoS could be cooked up. But NHRP
as it is today does not worry about QoS, so it does not have
criteria other than "find a shortcut along the same basic path as
the routed path." If NHRP had QoS criteria added, it would have to
test whether source and sink can be reached on the same ATM net. If
not, what paths are available that support QoS on the non-ATM
portions of the journey. These may be nothing related to the simple
routed path.

In short, I think a lot of careful thought would have to be put into
creating a generic version of NHRP that can support QoS requests.

Bert
[email-masked]