TCP_FSM Group mailing list

{Disarmed} About modularizing transports


Cronologico Percorso di conversazione 
  • From: Michael Welzl < >
  • To:
  • Subject: {Disarmed} About modularizing transports
  • Date: Tue, 19 Sep 2017 07:24:05 +0200
Hi,

I wanted to forward the email dialogue below - I find it very reassuring that this guy agrees with my split!

He implemented EFCP, which is the transport protocol in RINA, the Recursive InterNetworking Architecture. It’s a transport, all right, but differs from TCP in many ways. The “spec” (as much as a spec as it is…)  is here:

I followed this dialogue by adding that I forgot about a block called “connection state management”, to which he answered that *he* doesn’t need that, good protocols have no connection state…   well, that’s a different story, for a different day  :-)
Thinking more generally, I think we do need this, too.

I believe we can use the bachelor thesis from Brescia as a starting point, as it already implements many of the things below - and if we add the scoreboard + some timer logic (as a way to simplify the scoreboard!) to it, we end up with a modern, competitive TCP (and arguably, a scoreboard-like thing is necessary for all transports).

Cheers,
Michael


Begin forwarded message:

Subject: Re: A transport protocol implementation question
Date: September 14, 2017 at 12:00:01 PM GMT+2

Dear Michael,

It's good to hear from you. How's everything going?

the list of functional blocks you identified pretty much covers everything in the EFCP. One thing a bit different is that checksum calculation, and in general, the mechanisms and policies for SDU protection (you remember the RINA parlance, I'm sure) are not part of EFCP, and are carried out independently. Another thing is that in EFCP fragmentation and reassembly of SDUs has to be taken into account, though the details about this are part of a different protocol. But for the rest, it sounds right. 

Thinking about the code, these logical blocks are really separated. Of course, some of them are to be present in any instantiation of the protocol machines, and there are few things that are assumed to exist by several logical blocks. Though right now I can only come up with sequence numbers. 

Regarding a possible hardware implementation, I have the inkling that this separation, though works well in software, should be simplified in hardware, grouping together some blocks. 

I hope this helps you. Best luck with your efforts!

Best regards,

Miquel.


Libre de virus. www.avast.com

2017-09-08 15:31 GMT+02:00 Michael Welzl < " target="_blank" class=""> >:
Dear Miquel, dear Eduard,

I’m writing to you from my sabbatical in Rome, where I’m working with Giuseppe Bianchi.
For our research here, we’re trying to find common functionalities in transport protocols - to identify which of them could somehow be supported by hardware.
(instead of the very TCP-specific TCP hardware acceleration things that we have today)
This relates to SDN too …

So I’m trying to find out what the big functional blocks that make up transport protocols are - is there a way of “modularizing” protocols, so that we can find common functionality that could be put in hardware?

So far, I can see only a handful of things - but they come from thinking about TCP, and since you implemented EFCP you must have a very different view? So I hope this could help me!
(I read the spec of EFCP but it’s still a different mindset from someone who actually implemented it, I’m sure)

- send buffer management / communication with the application
- receive buffer management / communication with the application
- retransmission logic  (in TCP called the “scoreboard” - working with a data structure to find out which data was resent, which data was sent only once, which data has been ACKed, etc etc)
- congestion control
- flow control
- constructing headers
- receiving and parsing ACKs
- sending data packets
- sending ACKs
- checksum calculation

Does that sound about right, for EFCM too?  If not, what’s different?  And, if you think about your code, would you say that these things are really separate logical blocks, or is it all somehow mixed up together, or is it separated differently?

Cheers,
Michael




--
Miquel Tarzan
Distributed Applications and Networks Area - DANA
i2CAT Foundation
C/ Gran CapitĂ  2-4, office 203, Nexus I building
08034 Barcelona, Catalonia (Spain)


  • {Disarmed} About modularizing transports, Michael Welzl

Archivio con motore MhonArc 2.6.16.

§