Subject: Re: [core] HTTP over UDP

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Apr 2010 09:33:41 -0700

On 3/31/10 3:15 PM, Dave Horwitz wrote:
>> From: Carsten Bormann [mailto:[email-masked]]
>> Sent: Wednesday, March 31, 2010 12:11 AM
>>      
> My view is if any nodes *need* TCP then it's not "optional"
> in the protocol and must be specified as required for those
> nodes. Otherwise it's implied that some requirement is not
> being met?
>    
Agreed.  It is not reasonable for TCP to be a requirement.  The socket 
API for an underlying transport, in this case running over UDP, should 
be able to mimic the API used for TCP.
>> TCP likely will be more efficient that any lock-step protocol
>> based on range requests - do we need that efficiency?  TCP also
>> makes the state explicit that would be involved in a caching
>> scheme, but there may be other ways to do that.  Again, I have
>> not made up my mind yet.
>>      
TCP requires reassembly buffers when a packet gets dropped.  SCTP 
constructs over UDP would permit data framing for zero copy placement 
during packet loss, where only lost data is then retransmitted.  
Retransmissions would not include everything up to the last received 
byte, as with TCP.  Proper data framing also offers significant 
innovations for multi-casting as well.

-Doug

---

From: <[email-masked]>
Date: Thu, 1 Apr 2010 17:58:16 +0100

> byte, as with TCP.

um, SACK?

L.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Apr 2010 11:05:55 -0700

>> Retransmissions would not include everything up to the last received
TCP options are not always compatible with TCP anti-spoofing 
strategies.  Even if optionally supported, TCP-SACK does not eliminate 
reassembly buffers without data framing, as object boundaries might have 
been lost.  SCTP changed important rules engineered to run over UDP. :^)

-Doug

---

From: <[email-masked]>
Date: Thu, 1 Apr 2010 19:41:57 +0100

On 4/1/10 9:58 AM, [email-masked] wrote:
>TCP options are not always compatible with TCP anti-spoofing strategies.

and SCTP is not implemented on, well, anything. It's a protocol looking for a purpose.

What's your point, exactly?

L.

http://sat-net.com/L.Wood

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Apr 2010 11:34:32 -0700

> What's your point, exactly?
Lloyd,

SCTP just might be used by more people than TCP; something to consider 
when you place a call.  As such, SCTP offers a ready set of constructs.

SCTP is a protocol designed to offer robust and reliable control, 
directing messages of any size efficiently over common associations.  
SCTP was initially designed to run on UDP, but was then assigned an IP 
protocol ID of its own.  This was good, as now SCTP is supported by 
10Gb/sec NIC adapters along with math coprocessors able to offload its 
improved error checks.  SCTP adopted a polynomial with improved Hamming 
distance with comparable coverage for jumbo frames as IEEE CRC for 12Kb 
frames.  With faster instruction rates, overheads related to software 
CRC represents a diminishing portion of overhead when offloading is not 
available, while offering significant improvements in error detection 
rates.  TCP might fail detection for 2% of bit specific bus errors.  
With TCP's lack of framing, there is little assurance secondary checks 
are not neglected due to the complexity, or that data placement remains 
simple and without increased risks.

Home automation systems need to offer dependable and reliable services 
using minimal resources.  I worked on facility automation for military 
installations that were quickly decommissioned once communication errors 
became evident.  Don't ignore bus related error sources that occur 
beyond the PHY.  Power companies need to trust communications are not 
garbled by relaying devices.  With many homes able to produce power, it 
could prove fatal when excess energy gets placed onto the grid being 
serviced.  The goal of this effort should be efficient and reliable use 
of limited resources.  IMHO, applications will benefit more from socket 
compatibility in an environment lacking TCP support.

-Doug

---

From: <[email-masked]>
Date: Fri, 2 Apr 2010 22:56:04 +0100

Doug,

Yes, SCTP's CRC32c across packets is stronger than TCP's/UDP's 16-bit one's-complement checksum; I recall contributing to your RFC3309.

It's refreshing to see an understanding of the importance of errors and their detection; something that has been lacking elsewhere. (Thinking of the IRTF DTNRG here, which has spent years ignoring the importance of errors, including in relaying devices, and not understanding timing and the requirements of environments where these are important, and is now attempting to correct its bundle protocol for these oversights.)

However, SCTP is now an overengineered TCP-alike with bells and whistles that has been searching for new  applications since its SS7 roots (it does have a small niche in carrying custom protocols doing WAN acceleration in the Internet). If TCP is too large for an implementations, SCTP will also be. And not running over UDP poses firewall problems, no? Hardware offload isn't much use when resources really are minimal; TCP can be offloaded similarly, but will the hardware be there? And that doesn't help check the reliability of the data passed to such hardware, which needs its own internal integrity checks to defend against memory errors, etc. SCTP framing doesn't help with that, since that's still in the comms subsystem.

Is use of sockets really that compelling?

Anyway, we're diverging a bit from the subject line...

cheers,

L.

http://sat-net.com/L.Wood
________________________________________
From: Douglas Otis [[email-masked]]
Sent: 02 April 2010 19:34
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [core] HTTP over UDP

Lloyd,

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Apr 2010 18:53:19 -0700

On 4/2/10 2:56 PM, [email-masked] wrote:
> If TCP is too large for an implementations, SCTP will also be. And not running over UDP poses firewall problems, no?
Implementing a complete SCTP stack had not been suggested.  Rather than 
conditionally using TCP on occasion, and UDP for everything else,  a 
friendlier environment could be established using constructs established 
for SCTP used over UDP.  This would identify data-elements within every 
packet (data framing), provide good error checking, and allow similar 
association initializations.  TCP is unable to offer comprehensive 
security without conflicting options, nor can TCP provide simple and 
direct data placement, which helps in dealing with limited resources.  
Extensibility, such as mimicking the existence of a TCP transport as a 
layer above the transport constructs, could be achieved by leveraging 
APIs established for SCTP.  Basic configurations should eliminate 
multi-homing and perhaps restrict support to a few streams.  Rather than 
going to a single stream, permitting a few would allow multiple 
conversation to be bundled into a single packet.  This could supplant 
use of BEEP, for example.
> Hardware offload isn't much use when resources really are minimal; TCP can be offloaded similarly, but will the hardware be there? And that doesn't help check the reliability of the data passed to such hardware, which needs its own internal integrity checks to defend against memory errors, etc. SCTP framing doesn't help with that, since that's still in the comms subsystem.
>    
Processors are now many times faster than data passed over slow 
networks, which these devices are likely to use, where software CRC 
should not represent a constraint.  When networks become faster, it 
should be reasonable to expect servers will have math coprocessors, or 
hardware able to support speeds up to 10 Gb/s.
> Is use of sockets really that compelling?
Target devices are likely to represent some type of embedded OS.  By 
defining transport constructs, in addition to socket APIs, greater 
software diversity immediately becomes available, along with system 
interchangeability.  And yes, having a socket that mimics TCP permits 
HTTP over UDP.  UDP using transport constructs and socket APIs.

-Doug

---

From: Shidan Gouran <[email-masked]>
Date: Fri, 2 Apr 2010 23:29:24 -0400

+1 makes sense to me.

Sent from my phone

On Apr 2, 2010, at 9:53 PM, Douglas Otis <[email-masked]> wrote:

>> If TCP is too large for an implementations, SCTP will also be. And  
>> not running over UDP poses firewall problems, no?
> Implementing a complete SCTP stack had not been suggested.  Rather  
> than conditionally using TCP on occasion, and UDP for everything  
> else,  a friendlier environment could be established using  
> constructs established for SCTP used over UDP.  This would identify  
> data-elements within every packet (data framing), provide good error  
> checking, and allow similar association initializations.  TCP is  
> unable to offer comprehensive security without conflicting options,  
> nor can TCP provide simple and direct data placement, which helps in  
> dealing with limited resources.  Extensibility, such as mimicking  
> the existence of a TCP transport as a layer above the transport  
> constructs, could be achieved by leveraging APIs established for  
> SCTP.  Basic configurations should eliminate multi-homing and  
> perhaps restrict support to a few streams.  Rather than going to a  
> single stream, permitting a few would allow multiple conversation to  
> be bundled into a single packet.  This could supplant use of BEEP,  
> for example.
>> Hardware offload isn't much use when resources really are minimal;  
>> TCP can be offloaded similarly, but will the hardware be there? And  
>> that doesn't help check the reliability of the data passed to such  
>> hardware, which needs its own internal integrity checks to defend  
>> against memory errors, etc. SCTP framing doesn't help with that,  
>> since that's still in the comms subsystem.
>>
> should be reasonable to expect servers will have math coprocessors,  
> or hardware able to support speeds up to 10 Gb/s.
> interchangeability.  And yes, having a socket that mimics TCP  
> permits HTTP over UDP.  UDP using transport constructs and socket  
> APIs.
>
> -Doug
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core