[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] [ovs-dev] issue with OVS with SSL connection
From:       vishal.swarnkar () gmail ! com (Vishal Swarankar)
Date:       2011-01-07 4:34:16
Message-ID: AANLkTimRo=vR7zhB8G1OsyxaLjQjwMqfJkh7jynuByWD () mail ! gmail ! com
[Download RAW message or body]

>>You should look at the physical network to see where the packets are
getting lost or delayed, since it is possible that it could be happening in
any of a number of places.
I did a primary debugging and saw that time taken between eth0(saw using
tcpdump) and vport_receive is ~ 40 ms. I will see this in more detail.

>>Do you see retransmissions in the control connection (which could account
for delays)?
I dont see any retransmission in the control connection level, as the delay
is not that much significant.


>>As an aside, it's not a very good idea to tunnel your data plane Ethernet
traffic over a TCP connection like this, due to the mismatch in service that
each provides.  It will probably result in needless overhead, unusual
delays, etc.
The controller is in primary stage, so I am tunneling all my traffic for
now.

thanks
Vishal

On Fri, Jan 7, 2011 at 12:45 AM, Jesse Gross <jesse at nicira.com> wrote:

> I think you'll need to do some more debugging in order to get useful
> help on this.  You should look at the physical network to see where
> the packets are getting lost or delayed, since it is possible that it
> could be happening in any of a number of places.  Do you see
> retransmissions in the control connection (which could account for
> delays)?
>
> As an aside, it's not a very good idea to tunnel your data plane
> Ethernet traffic over a TCP connection like this, due to the mismatch
> in service that each provides.  It will probably result in needless
> overhead, unusual delays, etc.
>
> On Fri, Dec 24, 2010 at 11:20 AM, Vishal Swarankar
> <vishal.swarnkar at gmail.com> wrote:
> > Just to add ~
> >
> > When I make same setup over TCP, instead of SSL, then I don't see any
> > difference for a packet size > PMTU or < PMTU.
> >
> > thnx
> >
> > On Fri, Dec 24, 2010 at 9:44 PM, Vishal Swarankar
> > <vishal.swarnkar at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I am doing a basic test of OVS for OVS to NOX connection over SSL.
> >>
> >> Setup
> >> ========
> >>
> >> Machine 1 ( OVS, 10.2.0.111 ) -- connected to NOX over SSL ( NOX
> installs
> >> a flow : forward all packets to CONTROLLER )
> >>
> >> NOX : Whenever a packet comes forward it to all connected DPID.
> >>
> >> Machine 2 ( OVS, 10.2.0.121 ) -- connected to NOX over SSL ( NOX
> installs
> >> a flow : forward all packets to CONTROLLER )
> >>
> >>
> >> Tests
> >> ==========
> >> ping 10.2.0.121
> >> 9 packets transmitted, 9 received, 0% packet loss, time 8077ms
> >> rtt min/avg/max/mdev = 1.897/4.439/22.558/6.409 ms
> >>
> >> ping -s 1450 10.2.0.121 -c 10
> >> 10 packets transmitted, 10 received, 0% packet loss, time 9087ms
> >> rtt min/avg/max/mdev = 1.962/2.272/2.668/0.253 ms
> >>
> >>  ping -s 1460 10.2.0.121 -c 10
> >> 10 packets transmitted, 8 received, 20% packet loss, time 9087ms
> >> rtt min/avg/max/mdev = 2.128/2.855/5.691/1.104 ms
> >>
> >> ping -s 1472 10.2.0.121 -c 10
> >> 10 packets transmitted, 8 received, 20% packet loss, time 9098ms
> >> rtt min/avg/max/mdev = 1.995/2.332/2.684/0.225 ms
> >>
> >> ping -s 1473 10.2.0.121 -c 10   --- CROSSED the MTU size ( PMTU
> discovery
> >> results in 1500 )
> >> 10 packets transmitted, 8 received, 20% packet loss, time 9088ms
> >> rtt min/avg/max/mdev = 40.655/40.749/40.900/0.258 ms
> >>
> >> =========================
> >> I have tried this experiment 50000 times with the same results. After a
> >> packet size of ~1450, I can see packet loss and the moment packet size
> >> crosses PMTU, the response time jumps 20 times ( from 2 ms to 40 ms ).
> >>
> >> I tried to simulate same behavior with a simple tcp client/server.
> Please
> >> see the dump of a packet reception and its response from server. The
> dump
> >> was taken at eth0 of tcp server.
> >>
> >> 10.2.0.201 ( client ) sends a packet of size of 1448 to 10.2.0.121(
> server
> >> ).
> >> ===========================
> >> 14:10:14.234892 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [P.], seq
> >> 744272:745720, ack 16449, win 30720, options [nop,nop,TS val 2180291 ecr
> >> 2141105], length 1448
> >> Immediate ACK from Server Machine for 1448 byte packet -->>
> >> 14:10:14.234912 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [P.], seq
> >> 16449:16481, ack 745720, win 32, options [nop,nop,TS val 2141106 ecr
> >> 2180291], length 32
> >>
> >>
> >>
> >> 10.2.0.201 ( client ) sends a packet of size of 1548 to 10.2.0.121(
> server
> >> ).
> >> ===========================
> >> 14:12:20.400152 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [.], seq
> >> 29513:30961, ack 640, win 30720, options [nop,nop,TS val 2192911 ecr
> >> 2153722], length 1448
> >>  A delayed ACK from Server Machine for 1448 byte packet -->>
> >> 14:12:20.439894 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [.], ack
> >> 30961, win 32, options [nop,nop,TS val 2153730 ecr 2192911], length 0
> >>
> >> Rest of the packet (100 bytes)
> >> 14:12:20.440539 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [P.], seq
> >> 30961:31061, ack 640, win 30720, options [nop,nop,TS val 2192911 ecr
> >> 2153722], length 100
> >> Immediate ACK from Server Machine for 100 byte packet -->>
> >> 14:12:20.440563 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [.], ack
> >> 31061, win 32, options [nop,nop,TS val 2153730 ecr 2192911], length 0
> >>
> >>
> >>
> >> thanks
> >> Vishal
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev_openvswitch.org
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20110107/4242d5a5/attachment.htm>

[prev in list] [next in list] [prev in thread] [next in thread]