Subject: RE: [Forces-protocol] views on different channels vs same channel

From: "Putzolu, David" <[email-masked]>
Date: Thu, 4 Mar 2004 14:56:53 -0800

[hat off]
I agree with Jeff's clarification.  :)

The fundamental problem is shared resources - which can
occur in the OS, the app itself, or the physical link.  
Every component in a ForCES protocol stack implementation
has a role here:
* The app (ForCES agent on FE) needs to be properly 
  implemented - it may need to compensate for OS 
  deficiencies (by queuing as described in Ligang Dong's 
  presentation), it may need to appropriately signal the 
  OS so that the OS does proper queuing, and needs to 
  signal the OS with QoS hints so that the OS uses the 
  appropriate link level mechanisms.
* The OS needs to be properly implemented to differentiate
  flows and queue them appropriately (but some OS do not), 
  it also needs to accept QoS hints from the app and relay
  them to the link layer - that is, either direct different
  packets to different physical wires (some routers do
  this) or tell the link-layer it needs QoS support.
* The link layer needs to be properly implemented to 
  support QoS mechanisms - this can be physically
  separate wires, or treat packets differently based on 
  QoS hints from the app (via the OS).   Examples of the 
  latter include DMA channels as Jamal mentioned, or 
  other QoS mechanisms such as IntServ, DiffServ, VCs on 
  an ATM fabric, 802.1p in Ethernet, etc.

-David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of jeff pickering
> Sent: Tuesday, March 02, 2004 5:31 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Forces-protocol] views on different channels vs 
> same channel
> 
> Jamal,
> 
> I pretty much agree with 1), but would like to be careful 
> about the term 
> physical link.
> In your example, if you have multiple DMA channels "listening" on a 
> single physical
> backbone, you can provide reasonable DOS protection. So maybe 
> think of a 
> logical
> link as one where there is no overlap of underlying physical 
> resource. 
> The example
> above would be a reasonable approximation if the backbone is 
> much faster 
> than the
> DMA AND there was backpressure preventing backbone usage if one 
> channel's DMA
> is not available.
> 
> Jeff
> 
> Jamal Hadi Salim wrote:
> 
> >Hi,
> >since i have just scanned through tons of emails (halfway there),
> >let me share my view on the the topic. 
> >
> >1) If you are using the same physical link at the lowest 
> layer it doesnt
> >matter how many sockets/channels you have. The DoS impact is going
> >to be at the lowest layer i.e the physical link for which 
> the only cure
> >is to have separate links. The next level up is just before 
> the packet
> >is DMAed into RAM that the OS can get to it; there is some smart
> >hardware you can program to have multiple channels and drop at the 
> >earliest level. Majority of the hardware you will find cant do this.
> >Once the packet hits the OS, you can play with 
> differentiation/QoS/rate
> >metering of either the CPU time and/or bandwidth protection.
> >Summary: having more than one virtual channel within one 
> physical link
> >is going to offer little protection against DOS. 
> >
> >2)On the sending: the value is going to be in having multiple queues
> >just before the packet hits the OS.
> >For this you need to recognize something in the packet. This does
> >not imply the ForCES header needs some speacial signature; rather the
> >packet can be administratively recognized and classified 
> into a queue.
> >Example could be recognizing a destination IP or MAC address.
> >
> >3)
> >The idea of having such unique names to "channels" is almost 
> bell-head
> >approach. Reminds me of my ISDN days. There doesnt have to be a clear
> >cut explicit use for each channel (i.e thou shalt only transport data
> >packets). I am in agreement of having more than one 
> connection, but the
> >approach is different.
> >Like i shared earlier on our experiences: the way we had the 
> two or more
> >"channels" was to have different granularities of reliability.
> >We typically sent on a cheaper but less reliable mass 
> transport and on
> >failure if the message needs to be reliably delivered then it goes
> >retransmitted on a more reliable unicast channel.
> >
> >cheers,
> >jamal
> >
> >
> >_______________________________________________
> >Forces-protocol mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/forces-protocol
> >
> >
> >  
> >
> 
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 5 Mar 2004 12:01:22 +0800

Hi David,

I basically agree with your clarification. The only thing is that it seems quite hard to "signal" the OS with such QoS hints. 
 I'm not sure if or not this will induce to  implementation specific case,  because there are so many OS,  link layer 
mechanisms, and different scheduling means. On the other hand, even if this is possible, it still needs to be 
represented in ForCES protocol layer by use of mechanisms like FE capabilities, and FE attributes. This is quite
the same as GRMP, only GRMP tries to avoid being too OS and link layer specifc, therefore to define as much as possible
in ForCES protocol layer. 

I agree that to better solve the congestion problem, we need to use end-to-end QoS mechanisms. Actually TCP/SCTP/DCCP
themselves can not supply this, and OS mechanisms also cannot supply this. QoS protocols have to be combinedly used. 

Best Regards,
Weiming

----- Original Message ----- 
From: "Putzolu, David" <[email-masked]>
To: "jeff pickering" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 05, 2004 6:56 AM
Subject: RE: [Forces-protocol] views on different channels vs same channel

[hat off]

-David

ŠÜzÊk¢Ú¢YšŠX§‚X¬´Z+që)®‹hr‰bz×è®m¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£÷èÇ¬¦º-¡Ê%