The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1994-Sep> msg00171



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

one tcp per vc ???

  • From: ebcbghp@ebc.ericsson.se (SG/EBC/FB/FX Bengt Persson 08-764 0343)
  • Date: Wed, 28 Sep 94 14:16:07 +0100

On application level it is useally rather easy to qualify QoS parameters; 
 - Backup applications (very elastic)
 - A hartbeat function (delivery assurance important), 
 - Interactive Voice/Video (inelastic, loss prefered to delay)
 - Client/server application (low delay, also in fast networks)
If the application indicates the QofS, better resourse allocation is 
possible, also inside the hosts. If present, parsing this from passing 
protocol headers is possible. (In practice requires presence in the TCP 
header or a special resourse reservation protocol, as if it is in UDP or 
IP it will not be hard to know when to connect/release, and inspecting 
application info requires knowledge of too many application protocols).

But required QoS is not known by either TCP, IP or UDP today, and without 
such knowledge the IP over ATM driver can do nothing. Mapping TCP to 
ATM-VC 1to1 do not help much until the applications start delivering 
QoS to TCP. 

What may be done?

Short term:
 On the good side is that it does not matter VERY much as exisitng
 applications in general are very tolerant, and if not, the application will
 be foreced to be modified anyway (for reasons other than IP over ATM).
 Compare with the fact that bandwidth sharing on a LAN is "fair" only 
 between the attached nodes (routes, PCs and servers alike) not between 
 application-connections nor is it adapted needs. A workstation 
 making backgroud FTP gets as much as a host serving 100 users with 
 interactive database queries or a router carrying all external traffic, 
 i.e. unfair inoptimal use is accepted today.

Longer term:
 Enshure that QoS information is provided from applications (outside the 
 scope of this group, but within IETF: RSVP) or enshure that the transmission 
 networks, ATM and other, acts reasonable for any anticipated traffic 
 characteristics (outside IETF scope to develop but to state requirements).

 With this information the TCP/IP/ATM-driver may deside if new 
 connection is needed or an may be existing one used.

/Bengt