HP Networking
Discover how the new HP Networking combines the technologies and alliances of 3Com, ProCurve and TippingPoint into the next networking leader.

Stateless Transport Tunneling (STT): Yet another cloud encapsulation or next-generation VxLAN?

By Vishwas Manral, Distinguished Technologist, HP Networking, Advanced Technology Group

 

vm.jpgI have always tried to explore new topics in my blog and this time is no different. I recently saw the new draft posted by the Internet Engineering Task Force (IETF) that caught my attention. It is called Stateless Transport Tunneling (STT). But before I go any deeper on what it is, let’s take a few steps back.

                                                                                      

Last year was the year of VxLAN and NVGRE grabbing the cloud-world headlines! These solutions solved the multi-tenancy requirements in a virtualized data center by adding overlay tunnels (UDP in case of VxLAN and GRE in case of NVGRE). These complement solutions like TRILL and PBB that have existed for some time and are supported by various vendors. Stateless Transport Tunneling (STT) is the latest shiny new entrant trying to solve a similar problem in the already crowded field.

 

What is STT?

 

STT as defined in the draft is used for end-point-to-end-point tunneling and uses the TCP Segmentation Offload Capabilities (TSO) provided on Network Interface Card’s (NIC’s) resident on servers. The document is supported by Nicira, Broadcom, eBay, Rackspace, Intel and Yahoo. It uses the STT header and segments are sent encapsulated in the TCP header.

 

The good

 vm_1.jpg

 The fact that STT uses the NIC TSO capabilities is a great advantage. One of the big questions raised about software-based forwarding paradigms has been the performance, and that is what the STT solution is out to solve. Think of the case where a firewall/NAT where the NIC reassembles packets into huge 64k chunks and the number of packets that the middle box needs to look at is reduced considerably, maybe up to 50 times. I think this is a huge boost as we move into software-based paradigms.

 

Most current solutions have come up for support of up to 16 M tenants (24 bits). The STT solutions uses (64 bits) for the same, which multiplies the number of tenants by a considerable order of magnitude – no matter if that is required or not (it could help with flexibility in using the tenant space). The STT header also carries the VLAN tag besides the 64 bits mentioned above.

 

STT uses TCP segmentation to send out packets. This helps with the fact that there is no STT header overhead per packet for the segment header (though we still have the TCP header overhead). It also helps to make best use the link MTU.

 

The ugly

 

vm_2.jpgIf all communication were between servers in the same domain, the solution would be good in a lot of cases. However as we know, there is still north-south traffic coming into a data center (even though east-west traffic is now the bigger chunk). Since not every servers in the Internet will support this (or we may not virtualize every server), it means that the STT tunnels will have to be terminated somewhere in the data center. The problem however is that now such devices will need to be stateful and meticulously reassemble packets before they can be sent out for thee Stateless Transport Protocol to work (sounds like an anomaly).

 

Such traffic has to traverse firewalls/IDS/IPS and a lot of the other middle boxes if it has to be used end-to-end which looks deeper into the packet. If this were to happen with the STT solution, packets would need to be reassembled before they are sent out. This could lead to large overhead. For VxLAN or NVGRE as each native packet contains an outer packet, we can simply strip the outer header and we are god to go. We would not need to first reassemble the entire upper layer packet statefully.

 

There are probably other misgivings like TCP overhead, no ASIC support or mistaken middle boxes but the above concern seems to be so big that this could push the solution to be a niche solution – one to only be applied in particular markets only.

 

A final word on STT with a view to cloud computing

 

The efficacy of the new encapsulation technology will depend on the use cases and scenarios you may have. I hope the pros and cons defined will help you decide whether the technology is just another wannabe or the shiny new thing in the cloud-filled firmament. Let me know what you think on this topic!

 

You may also want to read:


>> VXLAN: consider the network virtualization technology cost angle

>> Enterprise networking reaching for the clouds: 4 steps to service-aware WAN

 

>> Learn more about HP Networking products and solutions.

>> Follow HP Networking on Twitter and Google+ | Join HPN LinkedIn Community | Like us HPN Facebook

Comments
Cristiano Monteiro(anon) | ‎03-22-2012 06:18 PM

Hi Vishwas,

 

I agree the traffic east-west will cause problems to middle box. However I´m a little confuse about the sentence below:

 

"If all communication were between servers in the same domain, the solution would be good in a lot of cases. However as we know, there is still north-south traffic coming into a data center (even though east-west traffic is now the bigger chunk). Since not every servers in the Internet will support this (or we may not virtualize every server), it means that the STT tunnels will have to be terminated somewhere in the data center. The problem however is that now such devices will need to be stateful and meticulously reassemble packets before they can be sent out for thee Stateless Transport Protocol to work (sounds like an anomaly)"

 

I mean I suppose STT was created to deal with the traffic among vswitch and  all the traffic north-south would  not be the encapsulated. So this  traffic should come and go from the datacenter wihout STT encapsulation. I understood the element responsible for STT encapuslation can also speak  regular TCP/IP. My analogy is a router that can deal with ipsec and regular lp. Am I missing something ?


Chiradeep(anon) | ‎03-23-2012 07:19 PM

It seems to me that all the overlay solutions have this limited utility of being applicable intra-datacenter. Nonetheless, when your IDS/firewall devices are actually virtual appliances, then the solution works better. Overlays + virtual appliances = IAAS implementor's heaven.

 

Also, while the STT proposal faults the other ones (NVGRE/VxLAN) for mixing responsibilities, it can be said that STT itself smells of a hack. Will be interesting to see if it becomes a standard.  

vishwasmanral | ‎03-27-2012 03:47 AM

Hi Chiradeep,

 

Cant agree with you more there!!!

 

What in your view is the holy grail for cloud networking?

 

Thanks,

Vishwas

vishwasmanral | ‎03-27-2012 03:52 AM

Hi Christiano,

 

Your understanding is correct there.

 

However if for some traffic we use one encpasulation and not for the others it may not help at all. Think of the case where 2 tenants use the same IP address. There would in my view be no way for traffic coming in to know where to go to in the DC network. 

 

Do I sound right?

 

Thanks,

Vishwas

Dave Lenrow(anon) | ‎03-31-2012 05:50 PM

Good Stuff Vishwas,

I think part of the issue is that folks think of IETF standards as needing to be applicable to the entire universe of IP based systems. Although most DC network gear speaks IP, it is often solving a completely different, much simpler, and narrower set of problems than those that IP was designed for (You and I have agreed that the nodes in your DC can't and won't survive a nuclear attack regardless of how autonomous they are and could be more efficent if not based on AS model. For example Igor G.'s assertion that he doesn't want discovery, he wants topology read from his inventory database).

 

I think you are correct that STT is only applicable to a subset of IP use cases (Intra-DC), but it is a huge subset and the fastest growing sector on the planet. I think much of the resistance to SDN and OpenFlow comes from similar analysis in a "global" context. Will these technologies be widely deployed by wireline/WAN carriers any time soon? No. But does that mean the folks who write off SDN/OF as a pipe dream are correct? Not at all. DC/Cloud deployments are happening.  Increasingly I think we will see networking solutions that speak IP on the wire, but don't implement the network through a completely distributed, AS model based on existing L3 standards. You have infinitely more IETF knowledge and experience than me, but I wonder if there is a need to somehow branch off working groups that standardize IP-related technology for verticals that don't care about solving problems on the entire Internet. It would at least cut down all the noise from folks that feel the need to criticize/refute proposals that solve a problem in a vertical, but don't make sense in other verticals. Maybe this is already reflected in the WG structure?

vishwasmanral | ‎04-02-2012 06:31 PM

Hi Dave,

 

Good points there. I agree DC related IP work could be different from the generic for all internet IP work.

 

IETF already allows work for these particular use cases. As an example this could be http://tools.ietf.org/html/rfc6554 RFC I authored and was published just a week back. It allows for changes to IPv6 for Sensor Networks only and does not allow any other changes at all. As part of the standard RPL effort from the ROLL Working Group.

 

Regarding SDN I think its a great technology. There are gaps that need to be solved (but that's normal for any new technology), and we can work on it. For the technology to be successful, it can't be everything to everyone, but start by focusing on particular verticals.

 

Thanks,

Vishwas

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
About the Author(s)
  • Editor and writer with 12+ years experience in the corporate software and technology sectors.
  • Teri is responsible for the social media program for the HP Networking and HP Storage business units. Teri has has held global roles in IT, Operations, Sales, Partner Programs, Communications, and Marketing at HP.


Follow Us