Logs for rohc@ietf.xmpp.org, 2004-11-08

[07:34:30] --- cabo--tzi--org has joined
[07:34:39] <cabo--tzi--org> Good morning everybody.
[07:47:48] --- admcd has joined
[07:48:57] --- rohc has joined
[07:49:16] --- rohc is now known as mark
[07:49:31] morning all!
[07:49:45] <cabo--tzi--org> Hi Mark -- is that you?
[07:49:57] yes
[07:50:11] can't be there in person, so this'll have to do!
[07:50:16] <cabo--tzi--org> Yes, I know.
[07:50:30] <cabo--tzi--org> We are looking for a jabber scribe right now.
[07:55:51] --- momose has joined
[08:01:45] <cabo--tzi--org> Lars-Erik gives introduction
[08:03:43] <cabo--tzi--org> Agenda: See http://www.ietf.org/ietf/04nov/rohc.txt
[08:04:45] <cabo--tzi--org> Document status
[08:05:10] <cabo--tzi--org> UDP-Lite ROHC has passed IANA, so we are expecting RFC publication in a month or two.
[08:05:56] <cabo--tzi--org> Documents "in" WG:
[08:07:35] --- gorryf has joined
[08:07:50] <gorryf> Cartsen provides updates on sigcomp-sip draft...
[08:09:55] <gorryf> Carsten says there are three issues with SIP
[08:10:16] <gorryf> 1) Do we want to do more for SIP? 1) Do we want to do more for SIP? 1) Do we want to do more for SIP? 1) Do we want to do more for SIP?
[08:11:16] <gorryf> There is only about 20% gain in stateless compression They therefore should really look at stateful or none at all.
[08:12:08] <gorryf> State would have to a part of the server fail-over. State would have to a part of the server fail-over.
[08:12:43] <gorryf> Are there any SIP implementors in the room?
[08:12:51] <gorryf> No response.
[08:13:05] <gorryf> 2) Do we need more for compartments?
[08:15:50] <gorryf> 3) TCP connections to setup sigcomp compression in middle of connection. 3) Do we allow TCP to be used for setup (in the middle)?
[08:16:03] <gorryf> L-E: Any comments?
[08:16:22] <gorryf> L-E resumes status update
[08:17:06] <gorryf> Main issue is to take ROHC-TCP forrward - Milestones still need updated! :-)
[08:18:00] <gorryf> ---------------
[08:18:04] <gorryf> Carstent: plan for taking sigcomp to DS
[08:19:43] <gorryf> RFC3320 - needs to advance (user-guide+torture test are expired and need to be resurrected)
[08:19:47] --- jnob has joined
[08:19:55] <gorryf> What is the statusof these documents?
[08:20:16] <gorryf> Cartsen notes lack of sigcomp implementors in room...
[08:20:26] <gorryf> L-E: are there any opinions?
[08:20:50] <cabo--tzi--org> Hello Mark?
[08:20:51] <gorryf> L-E: No response - we take this issue to the list.
[08:20:53] hello
[08:20:56] sorry
[08:20:58] <cabo--tzi--org> Opinion?
[08:21:00] was doing something else!
[08:21:12] we can resurrect user-guide + torture tests
[08:21:16] <cabo--tzi--org> Good.
[08:21:23] <cabo--tzi--org> Should we aim for DS?
[08:21:26] at least one person has some comments / suggestions for torture test
[08:21:31] yes -- we should go for DS
[08:21:58] <cabo--tzi--org> Can you send a short message to the ML reminding us of the comments/suggestions?
[08:22:04] certainly
[08:22:14] <cabo--tzi--org> Thanks.
[08:22:35] <gorryf> ------ Next on Agenda: TCP Update -----
[08:26:58] <gorryf> TCP problem with list compresion, if one option is not present the entire list compression fails.
[08:27:58] <gorryf> Carsten: There are many ways to do this - lets keep the mechanisms simple.
[08:28:20] <gorryf> We use English language to describe header chaining - should we use it here?
[08:28:35] <gorryf> ... but that's not formal notation.
[08:29:33] <gorryf> Cartsen (again): we can refer to the TCP Spec which says how to do the uncompressed case.
[08:29:57] <gorryf> ... OK but what do we gain, if we remove all the difficult cases from the FN?
[08:30:46] <gorryf> Carsten: we do have recursion in the FN - which we could use?
[08:30:53] <gorryf> ... but it would not look good.
[08:31:08] <gorryf> Carsten: But this may be a fast way to get resolution?
[08:31:24] <gorryf> .... We could use 3095.
[08:33:07] <gorryf> ... Continuing to look at control fields, and using parameters.
[08:34:34] <gorryf> Is passing parameters a workable solution?
[08:34:43] <gorryf> cartsen: what's the problem?
[08:34:44] --- jnob has left: Replaced by new connection
[08:35:49] <gorryf> Noitation defines just the packet formats, this defines only the fields, from F-N point-of-view this is moving state from the state-machine to packet formats (this is ciomplicated to describe)
[08:35:52] --- jnob has joined
[08:36:09] <gorryf> How do we get the info into the notation?
[08:36:51] <gorryf> ... Parameters to structure do not have context.
[08:37:31] <gorryf> How does the state machine build useful context? - All fields update the information.
[08:37:44] <gorryf> What is the advantage of parameters?
[08:38:20] <gorryf> - Control fields have similar properties to other fields.
[08:39:14] <gorryf> .... discussion of what is present in compressed format ....
[08:39:20] <gorryf> Cartsen: gorryf: TCP problem with list compresion, if one option is not present the entire list compression fails. gorryf: Carsten: There are many ways to do this - lets keep the mechanisms simple. gorryf: We use English language to describe header chaining - should we use it here? gorryf: ... but that's not formal notation. gorryf: Cartsen (again): we can refer to the TCP Spec which says how to do the uncompressed case. gorryf: ... OK but what do we gain, if we remove all the difficult cases from the FN? gorryf: Carsten: we do have recursion in the FN - which we could use? gorryf: ... but it would not look good. gorryf: Carsten: But this may be a fast way to get resolution? gorryf: .... We could use 3095. gorryf: ... Continuing to look at control fields, and using parameters.
[08:39:59] <gorryf> Cartsen: Every field has an encoding method. Why is a control field different?
[08:40:31] <gorryf> .... The question is how and where are these defined? - and do we refer to them?
[08:40:54] <gorryf> We tried to do this using a keyword (another suggestion is to use parameters).
[08:42:01] <gorryf> -------------
[08:42:21] <gorryf> Carsten goes through an example with a MSN
[08:47:26] <gorryf> discussion continues...
[08:51:41] <gorryf> Speaker resumes:
[08:52:31] <gorryf> FN has detracted from the atcual work on packet formats. WG would welcome anyone who has experience with TCP and compression - we need more effort.
[08:53:14] <gorryf> Is the box notation still useful? we need at some point to reconsider this?
[08:53:35] <gorryf> It does at least have the benefit of focussing the work on the packet format.
[08:54:05] <gorryf> Packet formats are not likely to change much - so these are now becomming stable.
[08:54:12] <gorryf> Are there questions?
[08:54:27] <gorryf> L-E: We resolved one issue (that of control fields)
[08:54:46] <gorryf> Yes, but not resolved the list compression decision.
[08:55:14] <gorryf> Some work is needed - the FN does not decsribe how to compress TCP Options
[08:55:41] <gorryf> Carsten continues with the FN discusssion.
[08:55:47] <gorryf> There are three issues:
[08:56:11] <gorryf> 1) List compresssion (look hopw much can be done in FN)
[08:56:41] <gorryf> 2) Interface between FN and state machine
[08:58:38] <gorryf> 3) Context use.
[08:59:21] --- jnob has left: Replaced by new connection
[08:59:40] <gorryf> - how to interface this? (we need english lang. description of second order info).
[09:00:46] <gorryf> What is missing actually? (every field has attributes, with representatio of how it is kept in the contect) is this enough?
[09:01:25] <gorryf> Carsten: how many packets do you send before you have an encoding context?
[09:01:41] <gorryf> - This isn't a FN issue. It's just needs to be stated.
[09:01:49] <gorryf> Carsten: correct, it's glue.
[09:02:04] <gorryf> - I thought this was laready specified.
[09:02:14] <gorryf> - What needs to be worked on?
[09:02:30] <gorryf> Carsten: Make sure there are no assumptions...
[09:03:36] <gorryf> End of presentation by Pelletier:
[09:03:39] <gorryf> ----------------
[09:03:47] <gorryf> L-E: ROHC RTP update
[09:05:00] <gorryf> Proposal to split RFC3095 into two documents framework & profile.
[09:05:36] <gorryf> Ambiguities etc collected in implementors guide. - but these affect the profile,
[09:06:02] <gorryf> What do we need to do? Can we go to DS (AD inputs needed).
[09:06:34] <gorryf> Is ROHC 3095 just too complex (some people think so) - it's tough for implementors
[09:06:49] <gorryf> Too many options for list compression?
[09:07:22] <gorryf> Another option is to generate new simpler profiles and go to PS?
[09:07:56] <gorryf> The new profiles would be given new profile numbers...
[09:08:30] <gorryf> Question: Does changing the numbers of profiles prevent progress to DS?
[09:08:47] <gorryf> LE: Not the only issue - significant changes may still be needed.
[09:09:21] <gorryf> LE: This is a new standard that does not interoperate with the old one.
[09:09:33] <gorryf> Carsten: Yes its interoperable.
[09:09:47] <gorryf> LE: Not if the two ends use different profiles.
[09:10:10] <gorryf> Carsten: Ok, taht's so. The real question is what we need to do to move from PS to DS.
[09:10:22] <gorryf> new mechanisms require cycling at PS.
[09:10:56] <gorryf> If we choose new mechanisms then we have issues, but if we use proven mechanisms, we shoudkl be able to move the new profiles to DS.
[09:11:20] <gorryf> LE The old profiles will be used - they will be implemented.
[09:11:43] <gorryf> Comment: RFC3095 is set in stone, and 3GPP refers to this.
[09:12:00] <gorryf> LE: This has problems, and needs fixes.
[09:12:18] <gorryf> LE: This works if you fix the bugs.
[09:12:53] <gorryf> Question: Is there anything in the implementors guide that changes things - the implementors guide does normative changes.
[09:13:05] <gorryf> LE: Let's not argue about what is normative.
[09:13:32] <gorryf> Carsten: if we do a new profile (0x101) then how do we handle this?
[09:14:00] <gorryf> - We could keep profile 0x01 alive - specified in the appendix?
[09:14:12] <gorryf> Question: Why do this if 3095 exists?
[09:14:33] <gorryf> LE: I'd rather put this in a separate document?
[09:15:11] <gorryf> Comment: ROHC use in 3GPP will over-ride the need to say how it works.
[09:15:48] <gorryf> LE: We should focus our effort on getting things right and say this is what goes to DS.
[09:16:01] <gorryf> Question: what to simplify?
[09:16:20] <gorryf> LE: List compression (remove extra complexity)
[09:16:37] <gorryf> Comment: Is it in scope to remove a mode?
[09:16:45] <gorryf> LE: Nothing out of scope.
[09:17:18] <gorryf> Carsten: We know of feedback on what is hard to implement (list compression is one of these?)
[09:18:05] <gorryf> Carsten: Do we have experience (documented)? Does the result of removing the features still fulfill the original RFC3095 requirements?
[09:18:29] <gorryf> LE: You can reject modes now.
[09:19:40] <gorryf> LE: Another issue is do we wish to FN when we re-define these?
[09:20:08] <gorryf> ROHC Implementors guide was updated 3 times since last IETF.
[09:22:25] <gorryf> Inputs requested on slope usage in decompressing RTP timestampes (please help) - for speech apps this is less of an issue - for video this is more messy.
[09:22:54] <gorryf> Comment: 3095 doesn't mention slope. Is it good?
[09:24:25] <gorryf> LE: This needs to be clarified (the assumptions are hidden in the text).
[09:24:51] <gorryf> carsten: do we have enough mechanism to cope with slope in 3095? Not sure thsi works!
[09:25:29] <gorryf> Comment: Ask the list to prove that "slope" exists and that there is some normative text.
[09:26:07] <gorryf> Carsten: The text (6.5.1) does not define a slope - other examples do provide an indication of slope.
[09:26:45] <gorryf> Comment: we need chair involvment in this debate. To give perspective on what was intended in RFc 3095, when it was written.
[09:27:19] <gorryf> LE: We did this study. I think the mail archives looked at this, and we took it away, and we may have lost some of teh debate.
[09:27:42] <gorryf> Comment: Do we have consensus?
[09:27:54] <gorryf> LE: OK. let's continue.
[09:28:25] <gorryf> ------- draft-brinkmann-rohc-3095-fn-00.txt ------
[09:28:32] <gorryf> Carsten speaks:
[09:30:07] <gorryf> Carsten is working on a 3095 implementation based on FN and have written a compiler that generates prolog code to see what the case is - wish to take pcap traces and run through the code.
[09:33:45] <gorryf> Comment: this effort is good, but takes the focus away from the actual tasks to eb achived.
[09:34:17] <gorryf> - I'm not convinced the FN makes it easier to undertand and helps implementors assess the issues,
[09:34:36] <gorryf> Carsten: the box notation is not accessible either.
[09:36:38] <gorryf> Comment: The readability of the standard does not matter so much in practive, H.264 is unreadable but complete.
[09:37:11] <gorryf> Comment: I think this is an experiment beyond the WG (let's do the work first).
[09:37:55] <gorryf> ------ LLA ROHC RTP Implementer's guide (Sandlund) ----
[09:38:35] <gorryf> Kristofer talsk:
[09:39:20] <gorryf> Payload length is needed - so that decompressor can recompute the CRC.
[09:41:24] <gorryf> Has anyone else implemented this?
[09:41:26] <gorryf> new issues to be sent to mailing list
[09:41:50] <gorryf> AM: This does not sound like a users guide.
[09:42:06] <gorryf> LE: This was discovered one month ago.
[09:42:18] <gorryf> AM: Be clear it updates the previous spec.
[09:42:44] <gorryf> Comment: Do we need to do this before we update the profiles?
[09:42:58] <gorryf> LE: We need to discuss procedure.
[09:43:12] <gorryf> ----- ROHC over channels that can reorder packets (Pelletier) ---
[09:44:19] <gorryf> Idea is to go to Info (not a proposal to update 3095).
[09:47:03] <gorryf> Comment: Early arrivals are fine
[09:49:15] <gorryf> Carsten: ECRTP also considers re-ordering issues. There is a paper to published - send a pointer to the mailing list.
[09:50:06] <gorryf> AM: There is work in voice over MPLS - they are meant to look at ROHC or ECRTP ?
[09:50:26] <gorryf> AM: Would that be a channel to right something about ECRTP?
[09:50:41] <gorryf> - The current trade-offs are not clear to me.
[09:50:50] <gorryf> LE: Whats the status of that work?
[09:51:22] <gorryf> AM: Requirement done. They could say MPLS LSPs don't do reordering, but that's not completely clear (routers can reorder)
[09:51:37] <gorryf> Comment: why does teh solution have to be specific?
[09:51:54] <gorryf> AM: The requirement is to use an IETF-based standards approach.
[09:52:11] <gorryf> Is there an implementors guide to help compare the two?
[09:52:41] <gorryf> Question: Is it possble to use ROHC?
[09:53:30] <gorryf> AM: I think that would be reasonable. They have an unusual compresssion for voice, and that needs to bve thought of?
[09:53:46] <gorryf> Who will feedback this?
[09:53:58] <gorryf> AM: people should go to the AVT meeting from ROHC!
[09:54:54] <gorryf> -----ROHC over 802 networks (Bormann)----
[09:55:13] <gorryf> Carsten presents:
[09:56:06] <gorryf> 2 issues:
[09:56:12] <gorryf> 1) Negociation
[09:56:39] <gorryf> 2) Encapsulation (including length, and overhead)
[09:56:49] --- admcd has left
[09:56:51] <gorryf> SNAP not desirable.
[09:57:10] <gorryf> Main problem is the minimum packet length.
[09:59:07] <gorryf> Must also be tollerent of added padding.
[10:01:34] <gorryf> Variety of modes some 802.11 bridges discard packets that are too short; some pad; most now seem to truncate at the correct length.
[10:01:55] <gorryf> How do you allocate a SSAP/DSAP?
[10:04:55] <gorryf> Cartsen: any questions?
[10:04:58] <gorryf> Question: Is this IETF work
[10:05:21] <gorryf> Carsten: This depends on L2
[10:07:26] <gorryf> Carsten: Who controls the demux identifiers?
[10:07:28] <gorryf> Gorry: the IEEE do have a web page that says they control the DSAP/SSAP registartion, at http://standards.ieee.org/regauth/llc/llctutorial.html
[10:08:26] <gorryf> Comment: ROHC would also be welcome to come to a BOF on IPv6/802.15
[10:08:50] <gorryf> Question: would it make sense to define how to do the approach in two parts?
[10:08:55] --- mark has left
[10:08:55] --- mark has joined
[10:09:00] <gorryf> Carsten: LLC exists and works,
[10:09:17] <gorryf> This is not likely to be the source of big problems.
[10:11:03] <gorryf> gorry: How do you see multicast/broadcast being handled?
[10:11:57] <gorryf> Carsten: It is in scope - we have teh idea of U-mode, that is applicable, and we can either use fixed config or some form of announecment.
[10:12:07] <gorryf> LE: Any more issues?
[10:12:11] <gorryf> None.
[10:12:16] <gorryf> ---- Meeting closes ----
[10:12:39] <gorryf> Goodbye from you note taker here in Washington DC.
[10:15:06] --- momose has left
[10:15:57] --- gorryf has left: Disconnected
[10:17:13] --- gorryf has joined
[10:17:39] --- gorryf has left
[10:51:03] --- cabo--tzi--org has left: Disconnected
[11:18:37] --- mark has left
[12:26:55] --- cabo--tzi--org has joined
[13:46:28] --- cabo--tzi--org has left: Disconnected
[14:22:12] --- cabo--tzi--org has joined
[16:53:39] --- cabo--tzi--org has left