* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mptcp Status Pages

Multipath TCP (Active WG)
Tsv Area: Mirja K├╝hlewind, Magnus Westerlund | 2009-Oct-15 —  

IETF-80 mptcp minutes


These are also available from the materials page:
mptcp proxy for mobility
demo set-up
draft-barre-mptcp-impl (pdf)
Autoconfiguring single-homed end systems to make use of network multi-homing
Session 2011-03-31 1740-1940: Congress Hall I - Audio stream - mptcp chatroom

iCal: ietf-80-mptcp.ics


mptcp minutes

          Multipath TCP (MPTCP)
          Meeting  : IETF80, Thursday March 31, 2011, 1740-1940
          Location : Prague, Congress Hall I
          Chairs   : Philip Eardley
                     Yoshifumi Nishida
          AD       : Wesley Eddy
          URL      : http://tools.ietf.org/wg/mptcp/
          Note Taker: Olivier Bonaventure
          1: Introduction  - Chairs
            Two RFCs were published. RFC6181 and RFC6182
            Need reviewers for protocol draft.
            Implementation available check inl.info.ucl.ac.be/mptcp
          2: Mptcp Protocol - Alan Ford
               Please send us the feedback
            Michael Welzl:
               I volunteer for reviwing
            Lars eggert:
               Is there another implementation besides ucl's implementation?
               If you are doing an implementation, please send feedback
          3: MPTCP Proxies - Mark Handley
            Lars Eggert:
              why wouldn't the mobile open connection to both proxy and server?
              it could do. But, you'll need to figure it out which one works and
              need to kill state on the server.
            Scott Brim:
              are the slides available?
              It's in the congestion control slide.
              cool thing you can use to do this is mobile IP homeagentr. This is
              winning combination. you want an initial rendez-vous point anyway
              for privacy
              not exactly the same role, it is similar, but proxy would need to
              behave differently with normal server and mptcp server
            Randall Stewart:
              there is IPR on this at a former employer, did similar thing for SCTP
            Scott Brim:
              had no idea this patent covered this, we'll ask later. extremely
              excited to
              see this model, you get 3 for 1, grab people who like mobile ip,
              don't need route
              optimisation, get privacy and get optimisation with mptcp
              one thing we need to do is to tell the proxy where to connect to
              and you need to
              do this in the syn would like to put an address in the syn, but we
              don't have space
              for this principles are easy, but in practice not easy to find the
              bytes should
              we try this on the first path in the protocol spec ?
            Anantha Ramaiah
              you seem to indicate mobility use case, but mptcp could be a general
              in such case all connections will go through the proxy. If the proxy
              knows that
              the server is mptcp capable and it does not need the flow anymore
              it might want to relay data at the beginning of the subflow to
              reduce latency
              you could do after the syn, but looks difficult
              take it offline
            Tim Shepard:
              mptcp proxy is used for everything and you have a long term
              relationship and
              have state in both ends, why not tunnel the information to the proxy
              gre would not go to nat
              TCP goes through NAT, could tunnel over TCP?
              maybe over UDP?
              mobile ip
              if you have wifi access point that is causing problem, does mip work
              there is nat on all these links
              tunnel might make sense
              udp tunneling makes sense to me, but don't like udp. it's cleaner
              to do it natively.
            Lars Eggert:
              assuming you could reuse some bits of the source ports, fragment
              ids, etc
            Alan Ford:
              data in the syn, wait for discussion in tcpm and work on spdy
              in google
            Tim Shepard:
              you know you are talking to a special box and you could use special
              acks to
              discuss with this box, think more evil
              Do we want this in the normal spec?
            Scott Brim:
              keep separate
            Lars Eggert:
              agree with Scott, don't hold the draft in the wg longer
            Tim Shepard:
              should not be in the spec? spec needs to encourage people to
              implement mptcp.
              this is just for proxy
            Alan Ford:
              don't know if this will be useful and wireless is uncontrol
              keep it separate but there is interest in the room
          4: MPTCP API - Michael Scharf
             Authors have corrected some minor issues based on reviews
             Document pretty stable, please provide further feedback
             Phil :
               There will be a WGLC after the next revision
          5: Coupled Congestion Control - Mark Handley
             3 reviews received for the previous draft, mainly wording and
             bytes/packets stacks. Draft has been updated to cover both and avoid
             rounding errors. Packet based version assumes that mss is same on all
             paths and draft describes how to handle the case if mss are different.
             NSDI2011 paper describes the algorithm in details and its performance
               We're running WGLC for this draft.
          6: Demonstration of Linux MPTCP implementation - Sebastien Barre
            Demo setup: two servers on 100Mbps links in a LAN with a programmable
            that inserts delay or losses between the two servers. servers are
            latest mptcp linux kernel implementation
            iperf running between the two servers, gets almost 200 Mbps at the
            application level
             Tecco Boot:
               why did loss on the blue link caused a reduction in bandwidth on
               the green one?
               related to retransmission that are done on the other flow,
               retransmission timeout may cause delays and fill receive buffer
             Mark Handley:
               congstion control is linked between the two subflows and this
               when both flows are equal loss, they get the same performance in
               modelling congestion
             Tim Shepard:
               all point is to move traffic away from congested path
             Tecco Boot:
               I would like to have a solution to react differently to losses
               and congestion.
               Looking for solutions taking traffic from satcom to 3G to wifi,
               mptcp could do
               some job there, you should use reliable link
               How do you detect whether the loss is due to congestion or due to
               something else?
                Without this info, we need to assume that they are caused by
               and not by link errors
             Georg Hampel:
               demo is very nice. What happens if there is a large delay, up to
               3 or 5 seconds?
               How do you create delay and loss?
               It's tc. artificial
             Michael Scharf:
               I like this demo, but independant of mptcp design, did the same
               demo with
               another protocol. could do it with a different protocol
          7: Autoconfiguring single-homed end-systems to make use of network
          multihoming - Rolf Winter
             Questions : do peole think it's useful?
             ??? :
               for experiments this is useful if you have a lot of time, but for
               normal usage,
               this is interesting for IPv6, multihoming on a single homed host
               with multiple
               addresses. how does mptcp work in this environment
               other scenarios are discussed in this document
               some discussion on ipv4 versus ipv6
                count show of hands: a dozen hands
          8: Rechartering - Chair
             Possible topics for rechartering
               Advice on implementation and heuristics ?
               Support for singl-homed end systems
               Applicability and experience
               Alternative security
               Alternative congestion control
               Advanced api
               Proxy for mobility
             Mark Handley:
               intend to spend some time on heuristics section, there is a lot
               we don't
               know, need good ways
             Scott Brim:
               I consider the following topics
                 applicability and experience
                 alternative congestion control
                 advanced api
                 proxy for mobility
               I hope somebody would work on these, I want to work on proxy for
             Tim Shepard:
               there should be a venue to do interop testing if there is
               a second implementation. nice to continue with a venue
             Phil: default option is to finish charter before the next ietf
             and pause
               while waiting for experiements and usage
             Alan Ford:
               We'll get more feedback as implementations progress
             Lars Eggert:
               nobody else is doing an implementation or knows another
               implementation ?
             Sowmini Varadhan from oracle:
               working on multipath for solaris
               a dozen people are helping in debuging and four are providing
               others are downloading merge in main linux tree is too early,
               need to stabilise and follow the draft
               be great if more people could contribute

Generated from PyHt script /wg/mptcp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -