Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft

"Jose Saldana" <jsaldana@unizar.es> Thu, 28 November 2013 08:58 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B211AD84D; Thu, 28 Nov 2013 00:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnlY47_wV_nI; Thu, 28 Nov 2013 00:58:56 -0800 (PST)
Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA4541AD8DB; Thu, 28 Nov 2013 00:58:55 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id rAS8wRsU013290; Thu, 28 Nov 2013 09:58:27 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: "'Tim Chown'" <tjc@ecs.soton.ac.uk>
References: <008c01cee5e1$9caa4590$d5fed0b0$@unizar.es> <CEB23B7B.663B%repenno@cisco.com> <01ee01cee6da$b05eb9a0$111c2ce0$@unizar.es> <6639F5EC-B9AE-471A-BEAA-D25D21526F21@netapp.com> <01da01cee768$42926af0$c7b740d0$@unizar.es> <3CD00280-AC5F-424C-9443-07064B2AE288@ecs.soton.ac.uk> <EMEW3|03e3a08ad2910f9d659aa138fccb1644pAM9wB03tjc|ecs.soton.ac.uk|3CD00280-AC5F-424C-9443-07064B2AE288@ecs.soton.ac.uk> <00c301cee9ba$90d91de0$b28b59a0$@unizar.es> <3E4AC0A1-51D3-415D-BD6B-E2EA7C424E83@ecs.soton.ac.uk> <EMEW3|06b2756ee52c882bf688759bbb3e3404pAQEwS03tjc|ecs.soton.ac.uk|3E4AC0A1-51D3-415D-BD6B-E2EA7C424E83@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|06b2756ee52c882bf688759bbb3e3404pAQEwS03tjc|ecs.soton.ac.uk|3E4AC0A1-51D3-415D-BD6B-E2EA7C424E83@ecs.soton.ac.uk>
Date: Thu, 28 Nov 2013 09:58:39 +0100
Organization: Universidad de Zaragoza
Message-ID: <005801ceec18$080a0e10$181e2a30$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/pFXgt4LgH+pyHEEB6KKfTqM8zAIc4popAgX21NgA+hAoBAKlUkKdAnqSMsoCjY1aegF1vL1DAWlAXWMBxTIImpjNbvMA
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: tcmtf@ietf.org, 'Martin Stiemerling' <mls.ietf@googlemail.com>, tsv-area@ietf.org, 'Spencer Dawkins' <spencerdawkins.ietf@gmail.com>
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: jsaldana@unizar.es
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 08:58:58 -0000

Hi, Tim.  I don't know if I understood well what you are proposing. Please
check the new text and tell me if it is what you meant.

Thanks a lot!

Jose

> -----Mensaje original-----
> De: Tim Chown [mailto:tjc@ecs.soton.ac.uk]
> Enviado el: miércoles, 27 de noviembre de 2013 15:58
> Para: jsaldana@unizar.es
> CC: tcmtf@ietf.org; tsv-area@ietf.org; 'Martin Stiemerling'; 'Spencer
> Dawkins'
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> 
> Hi Jose,
> 
> On 25 Nov 2013, at 08:44, Jose Saldana <jsaldana@unizar.es> wrote:
> 
> > Hi, Tim.
> >
> > I think it is a good idea and we should definitely explain the
> > scenarios in more detail.
> >
> > When you talk about a "deliverable which describes scenarios and
> > requirements," do you mean another draft? In the current "TCM-TF
> > reference model" draft, section 1.4 is about "Scenarios of
> > application". Would it be enough if we improve that section according
> > to what we have discussed in the last days?
> >
> > http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-05#section-1.4
> >
> >
> > Regarding the potential effects on other protocols, do you think we
> > should include that on the same draft?
> 
> I think the text now in the reference model v9 in point 8 covers the
> comment about scenarios.  It could be a separate draft, it could be the
same
> draft.
> 
OK!

> I'm not sure it addresses the issue of the impact on other protocols. This
> may be an axis on the design space?  And then to at least document the
> impact on other protocols of adopting the proposed combination of
> mechanisms at the three layers to be described in the reference model.
> Examples of these issues were raised at the IETF87 BoF, and may come up
> again in a future BoF if the charter doesn't include consideration of
them.
> 
Regarding the impact on other protocols, the current version of the Charter
says:

8. A first document (TCM-TF - reference model) will define the different
options which can be used at each layer. It will include a detailed
specification of the scenarios of interest. Specific problems caused by the
interaction between layers will have to be issued, and suitable extensions
may have to be added to the involved protocols. The impact on other
protocols will also be studied.

10. (...) The eventual impact of multiplexing on protocol dynamics (e.g. the
loss of a multiplexed packet, MTU-related issues) will also have to be
addressed.


So what you are proposing (if understood well) is something like this?:

The eventual impact of the combination of mechanisms proposed by TCM-TF on
the dynamics of already existing protocols will be studied and documented on
the TCM-TF- reference model. This is a (non-exhaustive) list of possible
interactions:

* Packet loss: The loss of a multiplexed packet may imply a number of
simultaneous packet losses affecting different flows. This may affect ...

* MTU: When multiplexing a number of packets, the packet size gets
increased, and this may produce some issues related to the Maximum Transfer
Unit of a network.

* more ideas?


> Will the reference model summarise the requirements, as distilled from the
> scenarios that are deemed to be in scope?

The requirements, in terms of maximum delay, etc., would be summarised in
the "TCM-TF recommendations" document.
> 
> Tim
> 
> >
> >
> > Thanks a lot,
> >
> > Jose
> >
> >
> >> -----Mensaje original-----
> >> De: Tim Chown [mailto:tjc@ecs.soton.ac.uk] Enviado el: sábado, 23 de
> >> noviembre de 2013 10:58
> >> Para: jsaldana@unizar.es
> >> CC: Eggert, Lars; tcmtf@ietf.org; tsv-area@ietf.org; Martin
> >> Stiemerling; Reinaldo Penno (repenno); Spencer Dawkins
> >> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> >>
> >> Hi,
> >>
> >> On 22 Nov 2013, at 09:50, Jose Saldana <jsaldana@unizar.es> wrote:
> >>
> >>> Hi, Lars.
> >>>
> >>> During the BoF in Berlin, I got the impression that the problem was
> >>> not the idea of TCM-TF itself, but some of the considered options
> >>> (e.g. TCP). There were many people who raised their hands when asked
> >>> about "willing to review docs or comment on mailing list". However,
> >>> it seems that there are some people who are not convinced about the
> >>> utility
> >> of TCM-TF.
> >>>
> >>> So in order to reach consensus, let us keep on discussing and
> >>> thinking. This is very enriching, since it is making us refine the
> >>> scenarios where TCM-TF may have a real potential, and discard the
> >>> ones
> > in
> >> which it makes no sense.
> >>
> >> I think it may be useful if the charter includes a deliverable which
> > describes
> >> scenarios and requirements. At present, the scenarios and existing
> >> solutions are presented in points 1-4 of the charter, rather than
> >> being
> > more
> >> formally documented as part of the WG activities. Such a document
> >> could explain why, from a requirements perspective, ROHC isn’t
> >> sufficient for
> > the
> >> use cases envisioned. It could also clarify what’s in scope, e.g.
> >> point 2 mentions satellite while point 10 mentions satellite as
> >> possible future work. There’s been some good scenario discussion on
> >> the list recently which could all be captured.
> >>
> >> What’s also missing is analysis of the impact on other protocols of
> > deploying
> >> soemthing like this; this concern was raised at the previous BoF.
> >>
> >> Tim
> >
> >