[Tsvwg] IETF 55 TSVWG Minutes - draft

[Allison Mankin <[e-mail]>]

[Send corrections/amendments to the chairs/Spencer asap]

Minutes for Transport Area Working Group (TSVWG)

Co-Chairs:	Scott Bradner <[e-mail]>
		Allison Mankin <[e-mail]>

Minutes:	Spencer Dawkins <[e-mail]>

Mailing Lists: 
General Discussion:[e-mail] 
To Subscribe: [e-mail] 
In Body: subscribe email_address 
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/ - or -
www.ietf.org/mail-archive/working-groups/tsvwg/current/maillist.html


----------------------------------------------------------------------------

Agenda

Transport Area Roundup - Scott and Allison - 30 mins

SACK/DSACK - Mark Allman - 15 mins
 Reading:
  draft-allman-tcp-sack-13.txt
  draft-blanton-dsack-use-02.txt 

Out-of-path signaling - 15 mins
  Towards a BOF in San Francisco, TBA

TCP MIB extension - Matt Mathis - 15 mins
 Issues:
  Any major functional area uncovered?  Comment now!
 Reading:
  draft-ietf-tsvwg-tcp-mib-extension-02.txt

Eifel - 10 mins - Reiner Ludwig
  Issue:
   Publish as Experimental? 
  Reading:
   draft-ietf-tsvwg-tcp-eifel-response-01.txt

F-RTO - 10 mins - Pasi Sarolahti
   Reading:
    draft-sarolahti-tsvwg-tcp-frto-02.txt
 
Framing topics - Discussion by authors  - 25 mins
 Reading:
  draft-culley-iwarp-mpa-01.txt
  draft-williams-iwarp-ift-00.txt

----------------------------------------------------------------------------

Allison and Scott did the Transport Area roundup 

  slides at 

    http://www.psg.com/~mankin/TSV55.html

DCCP is the newest group, DIFFSERV has been in 
  FIN/WAIT for a year or so waiting on its PIB, and ENUM 
  is almost finished (except for privacy). 

IEPREP is an interesting challenge. IPPM is well behaved, 
  and stands out against similar groups in other standards 
  bodies. Not making value judgments seems to help! 

IPS is doing its protocol and MIB work at the same time 
  (a first in IETF?) IPTEL is starting to work on IPTEL-related 
  URLs. MALLOC is waiting on its MIB; MEGACO has been 
  interesting but not pretty to watch. 

MIDCOM is a little chancy - need to decide what's reasonable. 
  MMUSIC is doing SDP additions (and has been for a while, but 
  it's been an orderly process), and has been useful to cellular. 
  NFSV4 is doing stuff (with 12 people - if you get your work 
  done you can get to the bar sooner). NSIS is doing the next RSVP 
  and is just rechartering - it may be doing MIDCOM follow-on work, 
  and it may take on the defense of RSVP extensions wrt other 
  standards bodies. PILC is almost finished (as soon as the 
  snake finishes digesting the last, big pig Internet-Draft). 

PWE3 is in transport, and why not? We ARE interested in congestion 
  control. Their requirements and framework documents are almost
  last-callable. RDDP is digesting individual submissions for 
  acceptance as working group docs. RMT isn't just reliable and 
  isn't just multicast, but its products are being used (by the 
  Post Office!), and their massive non-realtime spec went to 
  Experimental. ROHC compresses headers and is beloved of 
  cellular (big specs, small headers). RSERPOOL is moving past 
  requirements (diligently). SEAMOBY lost one of its jobs (but 
  is still looking at heterogeneous wireless links), and its 
  architecture is being looked at. SIGTRAN is still producing 
  documents. SIP has produced 20 documents this year and they're 
  being used by ITU-T and 3GPP. We've discovered that SIP telephony 
  is really IETF protocol space (security, congestion), and have 
  produced the largest protocol spec ever in the IETF, and 
  defined how to do SIP extensions only in IETF. SIPPING is doing 
  extensions  that don't change the SIP protocol.  SPEECHSC is voice
  recognition, and SPIRITS is doing its* call waiting for the Internet, 
  and TSVWG is doing lots of work, too - see below for details.
  Whew!

----------------------------------------------------------------------------

-- Status on using SACK and D-SACK - Mark Allman

The SACK I-D is mostly nailing down corner cases (at revision 13). 
  Have added a new and easier way to count bytes in flight that 
  fixed a lot of corner cases resulting from the old method (agree?) 
  and added threshold retransmission back.

The SACK I-D was hummed for Proposed Standard working group last 
  call and accepted by the meeting.

The Using D-SACK specification is trying to keep spurious 
  retransmissions from masking real loss. This is a detection case - 
  what to do when you detect spurious retransmissions is left to 
  another document.

There's an (expired?) draft from Mark and Ethan on responses, 
  and an EIFEL draft on responses. We don't need to tie detection 
  and response to progress detection. Sally Floyd - yes, decoupled.

----------------------------------------------------------------------------

-- Out-of-Path Signaling - John Loughney

NSIS is doing on-path signaling, and the recharter is making this 
  clear, but people in the working group are also interested in 
  out-of-path signaling, so we're meeting here as a mini-BOF.

Sven van den Bosch - Towards a BOF in San Francisco

Examples - signaling to NSIS forwarders that aren't on the data path.

Lots of interest - 100s of NSIS e-mails.

Why important? Facilitates deployment, easier migration path, 
  legacy equipment. There are existing products (risk of 
  incompatibility).

Concerns - Addressing, Self-healing (data plane and control plane 
  don't share fate), Security (additional threats to analyze).

Need to know next hop in control plane, need to tie to 
  routing tables.

Work should be done in IETF, coordinated with NSIS, 
  and interoperable with NSIS.

Need to focus on NSIS reuse, need to provide input
  to NSIS, need to ignore out-of-scope.

Allison - knowledge of the players in a signaling 
  environment the size of the global Internet isn't 
  scalable. How could this be limited to something 
  plausible and still be useful? ANS: Not per endpoint, 
  but perhaps per AS path. Use telephony as example.

Henning - we can only see this being scalable as a 
  directory service in an AS. We used DNS beyond that. 
  We don't need this to be globally scalable. 
  ANS: This is too difficult to solve in NSIS. 

Christian - Scott was referring jokingly to everything 
  over everything else (PWE3). Is this just overlay routing
  on top of IP? We always fall into the same trap - the 
  topology of the overlay doesn't follow the topology 
  of the Internet. ANS: The overlay isn't Internet-wide. 
  Christian - we also have experience with subsets 
  of the Internet.

John Wroclawski - process question - if this problem 
  is too ugly for NSIS, why is a second working group 
  with the same problem and the same people any 
  different? Allison: more time to focus on a different 
  problem than NSIS. NSIS is an Internet protocol - this 
  one isn't. John Loughney - speaking as NSIS chair, 
  there's overlap but not complete overlap in the interested 
  population and problem space. 

Rudiger Geib - I never thought about doing this 
  outside a single domain. 

Markus Brunner - in favor of this kind of work, 
  hoped to do it in NSIS, don't see concerns, 
  it's a small addition. 

-------------------------------------------------------------------

-- TCP Extended Statistics MIB - Matt Mathis

"When there's a problem, ask TCP". TCP already 
  measures the network, can measure the application, 
  and can adjust itself.

The hourglass hides the lower layers from the upper 
  layers. Good for growth but hides all the 
  performance bugs. Any single performance bug masks 
  all other bugs. TCP "tuning" is really debugging. 

Matt described the tables in the MIB. "Triage" instruments 
  show why TCPs stop sending - just figuring this out is 
  extremely valuable. Most of Matt's work is on bulk 
  transport, that's what comes out in the MIB.

135 instruments in 8 tables with separate controls 
  (based on your diagnostic needs) - is this worth the 
  overhead you save? Stats available for fast polling 
  on one connection and stats live after close (so you 
  don't have to catch them at FIN time).

Are the instruments complete? Do we call 'em bytes or 
  octets? Like the handling of retransmitted data? 
  Is the table partition and control appropriate?

Fixing false optimization in RFC 2012 - measure total 
  IP load, total data to application, subtract for 
  retransmissions.

"I'm not an SNMP/SMI genius" - some known issues 
  (timestamps? Microseconds? 64-bit-counter sizes? 
  Error semantics?

Process Issues - current IPv6 draft has good, 
  non-trivial transport extensions. IPv6 planning to 
  roll back to 2012bis, orphans good work. Pick it 
  up in our work? Need editorial help to make this happen.

Dave Thaler - it would be good to roll this work together 
  and pick up SMNP expertise in the process.

----------------------------------------------------------------------------

-- Eifel Response - Reiner Ludwig

Reiner cheated slightly and talked about both detection 
  and response, in a short overview of Eifel. These 
  started out together but have been split into two documents. 
  Detection has been nailed and will be revved and last-called. 
  Response should be more controversial, but there's no mail on 
  the topic. Last call to flush comments.

Yogesh Swami - if you have more than one TCP connection, you can 
  lose a lot of packets. What about change of subnets - a common 
  source of spurious retransmits. Scott - move this discussion 
  to the mailing list. Gogesh - testing with one TCP connection? 
  What is realistic for response analysis? ANS: Eifel doesn't 
  make TCP more aggressive. 

Allison hummed "should we publish the detection document as an
  Experimental now?" Following mailing list confirmation of this
  result, it will be placed on the IESG agenda for approval as
  as an Experimental.

---------------------------------------------------------------------------

-- F-RTO Update - Pasi Sarolahti

Pasi made a number of changes to the F-RTO algorithm based 
  on comments to 00 and 01 versions.

He's also added timestamped and SACKed variants of F-RTO.

Open issues: adjusting congestion control state when 
  spurious RTO is detected - causes problems in corner cases. 
  Can we make a general draft on congestion responses?

Need more mailing list discussion before this can be a 
  working group document.

Sally Floyd - are detection and response mechanisms 
  really orthogonal? There are three response mechanisms 
  on your slides - does it really not matter which 
  detection mechanism you use?

Marku Kojo - the idea of a generic response draft is to 
  provide guidelines. Mark Allman - should this be in 
  another document? The consensus was that we should decouple, 
  F-RTO is putting detection and response back together - 
  why are we doing this? ANS: It's possible to separate. 
  Yogesh - if they're coupled, we still have work to do. 
  Scott - need to take this to the list.

----------------------------------------------------------------------------

-- Framing debate - Allison says it's time to cut to the chase!

David Black - MDA iWARP draft sent here because it makes
  changes to TCP. IFT doesn't, but solves same problem. 

Paul - want to reduce copy overhead for network traffic, 
  reduce CPU overhead, and enable this at volume price 
  points. 10-Gigabit streams generate 20 Gigabits of data 
  when we copy them. We need to identify headers - if we 
  don't align, we have to buffer. Don't pack MSSes. Just 
  turn off Nagle (TCP_NODELAY).

Shouldn't do anything with data until TCP ACKs it? 

"Just buffer the data until it can be delivered" using 
  an elasticity buffer? Out of Order Delivery makes 
  this really big and expensive. We only need the elasticity 
  buffer if we're placing partial F-PDUs.

IFT - iWARP Framing for TCP 

Costs of markers don't justify benefits. Buffering is 
  still required for flow control. There's an 
  architectural cost of bugs that appear only when out 
  of order packets arrive. Implementation is bad for 
  existing TCP silicon, bad for software 
  implementations, conceptually ugly.

Unproven technology. Experiment, but use SCTP.

Ole, Broadcom - issues are cost and TCP compliance. 
  Cost - silicon vendors disagree with IFT assertions. 
  This is TCP-compliant - that was the goal. The issue was 
  packing, and we can fix that. 

Joe Touch - two semantics for TCP, on-the-wire and API. 
  If you give data to an application out of order, 
  you violate TCP. The problem is that we're changing 
  what it means to use TCP. We can call it something 
  else and use another protocol number, no problem. 
  ANS: The upper layer of DDP and RMA is going to 
  provide a reliable service, but it's not the same 
  upper interface. 

(sorry) Broadcom - DDP is about an application making a buffer 
  available to TCP anyway. There's a distinction between 
  placing data and delivering data. Once a buffer is provided, 
  it's OK to put data in it - but not to signal the receiver. 
  David Black - RFC 793 understands shared buffers and 
  requires clear rules for sharing. 

Pat Thaler - One of the reasons for putting a CRC in is 
  because the network can corrupt the data. If a protocol 
  doesn't include CRC retransmissions, it's at a disadvantage. 
  ANS: What's the alternative? Telling TCP that you really 
  didn't get the data you ACKed, so please retransmit?

(sorry) Sun Microsystems - there's no change in the wire protocol, 
  and the socket API being the sole API is debatable. 

Joe Touch - Need to be clearer about what's allowed between two 
  protocols. This isn't about sockets, it's about SEND and RECEIVE. 

Randy - Trying to get to SCTP level - won't give data to 
  applications. Scott - if we have to modify TCP, what's the 
  advantage over SCTP? Not available in hardware yet.

Pat - if one does RDMA over TCP, we can use the same stack 
  for applications that use TCP directly. Two protocols 
  would be prohibitive.

John Wroclawski - I would use SCTP instead of the twenty-year-old 
  protocol we're trying to retrofit!



_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg