Subject: [Tsvwg] Draft Minutes of TSVWG WG meeting - IETF 51

From: Allison Mankin <[email-masked]>
Date: Mon, 10 Sep 2001 11:26:47 -0400

With apologies for the late posting - please give any
corrections to us.

Scott and Allison

--------
Transport Area Working Group (tsvwg) Minutes
Wed, Aug 3, 2001 1300-1500pm

Chairs:  Scott Bradner and Allison Mankin

Notes were taken by Aaron Falk (many thanks to Aaron).

AGENDA:

Area report and WG status   - Chairs                   
TLS over SCTP               - Michael Tuexen           
SCTP Checksum               - Chairs                   
ECN nonce                   - Neil Spring              
Datagram Control Protocol   - Mark Handley             

********************

Area Report: Chairs

No comments or questions.  Powerpoint posted.
Watch for an announcement of the Transport Area web page,
which will include HTML versions of our semi-regular
area reports :)

********************

Status of TSVWG work: Allison

Discussion of current milestones - note that they need
to have revised dates.  No comments or questions.  The chairs
drew attention to the operative rules:

- working group drafts item should not (in TSV area, must not) 
  be accepted without being in the charter
- charter additions require AD approval
- charter addtions to tsvwg require IESG approval (we have
  12 ADs)

Chairs appreciate WG feedback on all charter determinations and
will try to keep the WG strongly in the loop.

********************

TLS over SCTP Discussion, Michael Tuexen

This draft was added to the WG because of a pressing need for
TLS support for SCTP for the AAA WG's Diameter security specification.
It is part of the chartered SCTP effort.  (The TLS WG asked for
the work not to be done there, as transport mappings were not in
their current charter).

  Randall Stewart: only a subset of streams use TLS? 
  A: yes, issue is how do you handle violations

  Comment: an additional feature that should be pointed out from SCTP is
  TTL, should these be only used on non-TLS? 
  A: yes

********************

SCTP Checksum Discussion, Chairs

  Allison: consensus support Sharp draft; seeking remaining dissent
  and a hum. This will replace specified Adler checksum which has poor
  properties for small packets. Jonathan Stone, a Stanford doctoral 
  student studying transport checksum issues, has pointed out both
  on the list and in private, as has Craig Partridge, his advisor,
  that it's impossible to get perfect protection over an unknown error 
  model, and by nature, transport protocols encounter unpredictable and
  varied error patterns, in contrast to a layer two protocol over 
  many kinds of single, physical links.

  Randall Stewart: are we talking about CRC-32 or ITU CRC-32c? Should
  get clarification before making a recommendation. Doug: difference
  is a better protection for jumbo frames. CRC-32c has better
  protection. IETF recommendation (CRC-32) degrades on jumbo
  frames.

  John Wroclawski: Monday night discussion (and advisory discussion
  by the TSV Directate) suggested that problem was
  not explored on list adequately. Recommend further list discussion
  of some of the new points suggested. E.g., last comment pointing out
  that error model makes a difference regarding performance of
  algorithm. There exist lighter weight and better error detection
  implementations that should be put into the protocol. It's not true
  that substituting a CRC for a checksum is equivalent.

  Scott: there is time pressure to get SCTP out.

  Doug Otis: Fletcher 32 has 2% error rate on bus, undermining credibility
  of checksums as algorithm.

  Comment: specify CRC vs. checksum today and close on polynomial later
  as a way to make progress.

  Stewart: Jonathan Stone working with Partridge found 50% of checksum
  failures due to packet splicing. Moving checksum to end would
  increase value of checksum. Also recommended changing Adler32. Also,
  noting that error model in use does not reflect error model in
  Internet.

  Comment: several groups want to know when this issue will solved and
  whether SCTP is stable and real, etc. Need to get this resolved
  soon.

  Allison:  note that SCTP is otherwise stable.  The other work is
  a clarification (the implementors' guide) that makes no changes.

  David Black: error model will drive selection of selection of best
  polynomial. Recommend different polynomial for link use.

  Comment: want to see this solved ASAP. If error model is application
  specific, then solution should not be in Transport but in
  Application.

  Wroclawski: If you do CRC at pkt head, should be sure solution works
  for big packets.

  Black: application specific checksum will drive application specific
  retransmit which is a bad idea.

  Scott: CRC vs. checksum? most hands raised for CRC.

  Scott: 32? 32c? talk another week? 32: few hands; 32c and talk:
  similar numbers. Action: talk on list more to more clear consensus.

  Comment: need to be sure solution for jumbo msgs doesn't eliminate
  use for small msgs.

  Stewart: CRC32 or CRC32c protect against internal copy errors in
  routers. checksums protect against link errors.

Consensus reported:  use a CRC, the polynomial to be discussed,
including chairs asking for specific mathematical help on
1. is it good/bad/indifferent for the CRC to be the same one
   as used in Ethernet?
2. is CRC32-whatever fine with both v. large and v. small packets?

********************

ECN Nonce Discussion, Neil Spring

  Wroclawski: how to say how when to set nonce bit?

  Christian Huitema: have you thought of load balancing effect with routers
  that see only half the flow? Would like to see a simulation. A: yes

  Matt Mathis: there are several different places where there are bad
  interactions between DF and other protocols e.g., PAWS. Should
  document.
  A: not clear what should be done?
  Allison: should record to document protocol interactions.

  Discussion of setting the DF bit per the draft -

  Handley: is it reasonable to turn off ECN if you can't do DF? 
  Sally Floyd:  this is a good policy question. If you can't set DF then you
  don't have protection about whether the receiver was lying. Different 
  busy web servers may call it differently. Mark: Does the IETF want to make
  a recommendation one way or the other? Sally: not necessary at this
  point to recommend that you don't use ECN unless you can use DF.

  KC: Is Nonce a must for ECN? Sally: no, ECN was standardized without
  it. So, nonce was not a must. (KC = Kacheong Poon?)

  Wroclawski: it's not a requirement but it *is* a really good idea and
  should be encouraged. Does it make sense to use nonce only on low
  order fragments? Sally: Nonce doesn't give very good protection if
  you can't set DF. David: text says that reassembly of fragments may
  not behave well when nonce bit is set differently on fragments.

  Scott: ready for last call for standards track or need more
  opinions? Sally: ready for last call. 
  Clear show of hands to last call.

Consensus: we will WG last call this for standards track after IETF.

********************

Datagram Control Protocol (DCP) discussion: Mark Handley

  Wroclawski: does DCP allow for third party cc algorithms? A: yes, a
  user-specified option exists but in kernel space. 
  Wroclawski: kernel/user space is arbitrary distinction.

  Floyd: choice is either to design protocol like this or to encourage
  implementers to enable UDP users to use ECN. Don't want the
  latter. Wroclawski: don't want to prevent kernel implementation but don't
  want to count on it.

  Henning Schulzrinne: compared DCP to SCTP and UDP as alternatives, couldn't
  this also be used to negotiate TCP congestion control algorithms as well?
  Mark: you can probably do it but may not want to.

  Stewart: don't know how to set ECN bit unless you're superuser. USCTP
  is not right choice for real time apps but it does have limited
  retransmit.

  Comment: DCP give good solution for real time protocol without
  architectural hacks at RTP or architectural level.

  Huitema: most folks no longer look at socket interface when
  programming networks. DCP appears to be designed with one single
  rationale: to do a UDP stream with congestion control. Perhaps we
  should do a requirements analysis before we design a new transport
  protocol. For example, its necessary to work with firewall and NAT
  vendors for support. E.g., RTP does much of this but adds time
  synchronization. Should we add this to DCP? Also, perhaps we should
  have support for true Transport layer security?

  Comment: Merging with RTP is a bad idea because you might want to
  degrade audio and video seperately in a stream were all the streams
  are integrated in a single RTP stream.

  Jim Renkel, 3COM: I implement multimedia gateways in a dedicated
  carrier network. RTP is sub-optimal for my applications. Besides,
  VOIP, Fax-over-IP and Modem-over-IP would be able to use DCP better
  than RTP. However, RTP has good statistics and time
  synchronization. These features should be added to DCP. Need to be
  sure negotiated features and be extended to support this
  stuff. Also, want to add some ability to support forward error
  correction. A (Mark): can use RTP over DCP to get extra features. Jim:
  layering multiple protocols is inefficient and wasteful.

  Comment: we're not taking advantage of IP multi-homing. Should be
  sure to support multi-homing in the features here? Mark: we've been
  trying to be minimalist and didn't consider it. Might be
  considerable.

  Phil Conrad: tech concern: typically setting up multiple media
  streams in parallel (video, audio, chat, etc). Do you coordinate
  ways of having multiple streams sharing congestion state? SCTP can
  do this. May be duplicating effort with SCTP. 
  Allison: Endpoint congestion manager may address this desire.  Note
  ECM has become a Proposed Standard (RFC 3124).

  Wroclawski: it's difficult to deploy new protocols because of a)
  implementation complexity and b) firewall complexity and other
  reasons. Because of all the overlaps between different transport
  protocols, perhaps we should consider moving to an approach of using
  multiple building blocks that can be combined usefully.

  Comment: SCTP may be modified to have negotiable congestion
  control.

A consensus call was not made but the chairs stated that they did
not expect to ask for chartering of DCP work within this working group,
but did wish for comments on the general approach for protocols for
varied congestion control and variable reliability.

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 10 Sep 2001 14:44:05 -0700

> 2. is CRC32-whatever fine with both v. large and v. small packets?

Allison,

1)
The CRC within the medium should be considered a separate subject.  Perhaps
there is a subtle case where having two different polynomials offers better
protection, but each CRC will have a different offset in any case.  The
desire to use a different polynomial was fostered from a need to offer
greater channel protection for larger packets.  A good channel is designed
such that, if a few errors occur in transmission, the output can still be
verified.  Hamming distance is the number of symbols or bits that change
between two sequences or strings.  Selecting a polynomial with a greater
Hamming distance allows detection of a larger distance arising from errors.
Using this error detection criteria, a benefit is offered by CRC-32c over
ITU-CRC-32 as a result of the improved Hamming distance that is pronounced
in the realm of jumbo frames.  If the transport checksum is seen as overall
protection, then the medium CRC plays only a small role in detecting
possible transit corruption.

2)
Unlike a checksum that depends on an odd modulo to randomize bits, a CRC
offers this property on even the smallest packet size.  The protection
offered by CRC greatly improves with smaller packet sizes unlike checksums
such as Adler-32.  For cell mis-sequencing or massively corrupt packets, any
polynomial will likely offer similar protection.  Due to the inherent random
nature of CRC codes, CRC itself appears to offer a substantial improvement
over other types of checksums with respect to massive corruption as seen
with bit fault testing.  In short, CRC becomes nearly ironclad for small
packets unlike checksums.

I hope this helps, but I would not claim to be a mathematician.

Doug