Subject: Issues for Colip or Intserv

From: [email-masked] (KATSUBE Yasuhiro)
Date: Tue, 23 May 1995 02:09:42 +0900

Hi all,

Excuse me for duplicate mails if you subscribe both Int-serv and Colip 
mailing lists. 

I would like to raise a couple of issues that would be worth discussing
at Stockholm, either Intserv WG or Colip-bof. 

I have been trying to clarify issues with regard to a provisioning of 
end-end QoS over a network with a variety of datalink platforms connected
by routers. 
Issues are currently classified into the following items in my mind;

   1) End-end protocols for bandwidth/QoS assurance (RSVP, STII)

   2) End-end service definition and desirable control functionalities 
      for the service (Intserv)

   3) Interaction/interface between IP and datalink layer technologies 
      (Colip?)

1) is what we have been discussing at RSVP and STII, while 2) is what
we have been discussing at Intserv.   As you know, 1) and 2) are not 
independent from each other.  Outputs of 2) will especially affect 1). 
For instance, concrete definition of individual services, and policing/
shaping policies for these services will affect both semantics and 
syntax of resource reservation.  
I believe that these issues will be further investigated in RSVP and
Intserv WG. 

I see that 3) includes issues on both CO (Connection-oriented) datalink
and CL (Connectionless) datalink as follows; 

- CL datalink : When network nodes (hosts/routers) are attached to 
  shared-medium CL datalink such as Ethernet/token-ring/FDDI, available 
  output link rate for each node varies from time to time due to 
  contention to the medium.  When nodes are attached to dedicated CL
  datalink such as EtherSW, on the other hand, available output link 
  rate for each node can be its physical interface rate (e.g., 10Mbps, 
  100Mbps).  However, due to contention at output ports of the switch, 
  especially at the backbone switch, each node cannot surely estimate 
  available bandwidth toward their adjacent nodes as there is no 
  bandwidth reservations over these CL datalinks. 

  Don't we have to investigate bandwidth management and queueing control
  issues over CL datalinks in order to provide a specific end-end QoS? 
  What is the interface bw. RSVP admission control module and datalink
  specific bandwidth management module? 
  Or should we use CO datalinks such as ATM when we run RSVP? 

- CO datalink : CO datalinks such as ATM and FR seems suitable for the
  provision of QoS-IP service since each node can reserve certain 
  bandwidth toward adjacent nodes by setting up VCs.  With regard to 
  relationships between each reserved IP flow and datalink VCs, there
  has not been enough discussion so far, or it seemed to be a vendor
  specific issue.  Some vendors may let all IP flows share a single VC
  while some other vendors may let each IP flow use a dedicated VC. 

  How should routers specify VC's traffic/QoS parameter in each case? 
  What is desirable flow mapping policy to datalink VCs? 
  Can we leave these issues completely vendor specific?  Shouldn't we 
  share some common view regarding these issues, and give some helpful
  guidelines for vendors or users? 
  Aren't there any technical breakthrough for routers by making use of 
  characteristics of CO datalinks? 

I am wondering if we have chance to discuss issues related to item 3)
at Stockholm Colip-bof or Intserv WG for the provision of end-end QoS 
over any datalink. 
I am afraid that my statement in this mail may not clarify issues very
well, but I appreciate it if you could give me any comments or 
suggestions. 

I will post an Internet-draft that is related to item 3) very soon. 

Regards.

Yasuhiro Katsube
Toshiba R&D Center

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 May 95 19:41:32 JST

>   100Mbps).

EtherSW with dedicated link is rather CO than CL.

>  However, due to contention at output ports of the switch, 

You should use multiple prioritized queues at the output port. There
is no contention, then.

>   issues over CL datalinks in order to provide a specific end-end QoS? 

I don't think there are any differences between CO and CL links except
that, on CL links, QoS can be satisfied only statistically.

ATM and frame relay raises a different issue other than CO/CL.

That is, unlike a simple dedicated line, which is also CO, ATM and
frame relay offer multiple link layer connections with different
QoSes.

>   Or should we use CO datalinks such as ATM when we run RSVP? 

It depends on what type of QoS is requested by a specific RSVP session.

But, it can be said that, if all the QoS requirement we will have
can be satisfiable without cell relaying technology, there is no
reason to use ATM. Use IP over SONET, instead. So, if you say ATM,
let's assume we'll have a very hard QoS requirement satisfiable only
with ATM.

>   Some vendors may let all IP flows share a single VC

It depends on what type of QoS is requested by a specific RSVP/ST-II
session.

>   How should routers specify VC's traffic/QoS parameter in each case? 

Routers doesn't make any judgement but just translate transport
layer QoS requirement to link-specific requirement. It's router
local issue and has nothing to do with the protocols.

>   What is desirable flow mapping policy to datalink VCs? 

It depends on what type of QoS is requested by a specific RSVP/ST-II
session.

>   Can we leave these issues completely vendor specific?

Vendor difference has nothing to do with them. Routers which can't
satisfy the transport layer QoS requrement because of wrong
translation to the linke layer QoS are just broken.

							Masataka Ohta

---

From: [email-masked] (Hiroshi Esaki)
Date: Wed, 24 May 1995 14:13:04 -0400

I think you should discuss this issue NOT including int-serv. 
This is more related to data-link. 

Just one simple commnt. 

   >   Or should we use CO datalinks such as ATM when we run RSVP? 

NO!.  ATM is just one datalink platform, that would be appropriate 
to support RSVP flows. 
If the CL datalink is fast enough, who cares what technology is used 
at data-link. 
Router basically decides how to use datalink in order to transport RSVP 
flows, I think. 

  >> It depends on what type of QoS is requested by a specific RSVP/ST-II
I think the flow mapping policy also decided by router itself. 
Who can enforce the flow mapping policy ? 
You may give some examples, but it will be just example. 
Yes, the guidline how to mapp/aggregate flows is valuable to discussed, 
I think.   I think this should be discussd at colip-mailing-list, rather 
than int-serv. 

Regards,

Hiroshi Esaki