Subject: [core] (no subject)

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Apr 2010 11:19:34 +0300

>>> I am unconvinced of the utility or practicality of a TCP interface for 
>>> this protocol. In any case where TCP would be considered, I think a 
>>> protocol such as HTTP would likely be better suited. My thinking is that >>> any device powerful enough to do proper TCP would surely be powerful 
>>> enough to do simple HTTP.

>> You know, I totally agree with that approach. The recent conversations 
>> around SCTP and UDP/TCP negotiation have made me even more unsure if we 
>> need to define a TCP binding at all. Maybe we end up just saying that if 
>> you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-)

> I mentioned this, but later I was thinking about the possibility of using > this protocol over RS-232 serial line... It might be useful to define how 
> the protocol could be used in this way, but to recommend against using it > over TCP. *shrugs*

It depends on both the line speed and application. Some of the interfaces mentioned in discussions here are as low as 1200 bps (DALI). RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces power requirements by going down to 10000 bps. 

A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone, before the actual data gets sent. With a 1200 bps cable, that's over a 1-second additional delay just to use TCP instead of UDP. This could be acceptable for some sensors, and for controlling HVAC or even a fire alarm, but I don't think it would be acceptable for a light switch talking to a lighting fixture.

Still, where timing is not critical, it's always a good idea to allow packets to be sent through an arbitrary amount of hops, through VPN, or whatever. And there's no beating TCP for getting the packet through. It takes the burden of reliability off of the application developer, so I guess it really should be in there, with the appropriate caveats. Just as long as not every light switch and lighting fixture need to support TCP for this.

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Wed, 21 Apr 2010 10:16:34 -0400

If there are concerns with the TCP 3-way handshake, I would suggest at
least giving a peek at T/TCP (RFC 1379 and RFC 1644).

- Robby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Wednesday, April 21, 2010 4:20 AM
To: [email-masked]'
Subject: [core] (no subject)

>>> I am unconvinced of the utility or practicality of a TCP interface 
>>> for this protocol. In any case where TCP would be considered, I 
>>> think a protocol such as HTTP would likely be better suited. My 
>>> thinking is that >>> any device powerful enough to do proper TCP
would surely be powerful enough to do simple HTTP.

>> You know, I totally agree with that approach. The recent 
>> conversations around SCTP and UDP/TCP negotiation have made me even 
>> more unsure if we need to define a TCP binding at all. Maybe we end 
>> up just saying that if you want to use TCP, then go ahead and use 
>> HTTP (okay, shoot me) ;-)

> I mentioned this, but later I was thinking about the possibility of 
> using > this protocol over RS-232 serial line... It might be useful to

> define how the protocol could be used in this way, but to recommend 
> against using it > over TCP. *shrugs*

It depends on both the line speed and application. Some of the
interfaces mentioned in discussions here are as low as 1200 bps (DALI).
RS-232 can handle 2400-19200 depending on cable length. 802.15.4 reduces
power requirements by going down to 10000 bps. 

A TCP packet over IPv6 is at least 60 bytes (480 bits) not counting
layer 2 overhead. That's almost 1500 bits for the 3-way handshake alone,
before the actual data gets sent. With a 1200 bps cable, that's over a
1-second additional delay just to use TCP instead of UDP. This could be
acceptable for some sensors, and for controlling HVAC or even a fire
alarm, but I don't think it would be acceptable for a light switch
talking to a lighting fixture.

Still, where timing is not critical, it's always a good idea to allow
packets to be sent through an arbitrary amount of hops, through VPN, or
whatever. And there's no beating TCP for getting the packet through. It
takes the burden of reliability off of the application developer, so I
guess it really should be in there, with the appropriate caveats. Just
as long as not every light switch and lighting fixture need to support
TCP for this.
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 21 Apr 2010 11:05:14 -0400

T/TCP has some great properties (better channel
utilization, per-host rather than per-session state)
but has some well-know security issues we'd have
to address: http://www.mid-way.org/doc/ttcp-sec.txt

Re: serial comms, many RS-232 ports support
115.2Kbps . SLIP is the least complex encapsulation
scheme (RFC 1055) but hasn't been updated for
multi-protocol support, which is addressed here:
http://ftp.rodents.montreal.qc.ca/pub/mouse/docs/ipv6-slip

-K-

---

From: Robert Quattlebaum <[email-masked]>
Date: Wed, 21 Apr 2010 08:56:49 -0700

> Still, where timing is not critical, it's always a good idea to allow packets to be sent through an arbitrary amount of hops, through VPN, or whatever. And there's no beating TCP for getting the pa…

I think I was misunderstood. I was referring to using a serial line in the same way that a TCP connection would be used. No IP encapsulation would be necessary---the only protocol used would be CoAP. One end of the serial line would be a CoAP device, and the other end could be a CoAP proxy...

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 09:16:46 -0700

On 4/21/10 1:19 AM, Yoav Nir wrote:
>>> You know, I totally agree with that approach. The recent conversations around SCTP and UDP/TCP negotiation have made me even more unsure if we need to define a TCP binding at all. Maybe we end up just saying that if you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-)
>>>        
>> I mentioned this, but later I was thinking about the possibility of using>  this protocol over RS-232 serial line... It might be useful to define how the protocol could be used in this way, but to recommend against using it>  over TCP. *shrugs*
>>      
When each packet contains a verification tag (to identify an 
association), good error detection, transport sequence numbers, with TLV 
data framing, then associations can persist while retaining little 
state.  Slower networks should safely allow use of smaller fields.

SCTP demonstrated establishment of associations (TCP connections) with 
data exchanged sooner than with TCP, while also avoiding source spoofing 
and sync-flood attacks.  Persistent associations permit single packet 
exchanges on par with that of UDP.   But unlike UDP or T-TCP,  
recipients are able to detect source spoofing, and to determine packet 
loss.  Keep-alives or heart-beats should be optional.

Modes of operation would be negotiated when an association is 
initialized.  With UDP, ordered or reliable delivery is not assured, so 
there should be a mode offering unordered unreliable delivery to mimic 
the dynamics of UDP.  By including selective and cumulative transport 
sequence number acknowledgment, delivery modes well beyond what is 
offered by TCP becomes possible.

The TLV data chunk used by SCTP for selective acknowledgment contains 
the following:

Cumulative TSN Ack
Advertised Receiver Window Credit
Number of Gap Ack Blocks
Number of Duplicate TSNs
  Gap Ack Block #1 Start
  Gap Ack Block #1 End
  Gap Ack Block #N Start
  Gap Ack Block #N End
  Duplicate TSN 1
  ...
  Duplicate TSN X

Modes of delivery for unicast and broadcast transmissions could include:

1) unreliable unordered delivery (without receiver or transmitter buffering)

2) unreliable ordered delivery (without receiver or transmitter buffering)

3) reliable unordered delivery (without receiver buffering)

4) reliable ordered delivery (with receiver and transmitter buffering)

TCP only offers unicast reliable ordered delivery with receiver and 
transmitter buffering, but then lacks data framing.  Data framing 
permits inclusion of information within each packet to enable zero copy 
placement of data received out of order.

A socket API, much like what had been defined with SCTP, could easily 
mimic the mode of operation offered by TCP, while consuming less buffer 
resources, network traffic, while having lower latency and much higher 
reliability.

-Doug