Re: [tcmtf] tcmtf Digest, Vol 19, Issue 13

Mehmet Karaca <mehmet.karaca@airties.com> Fri, 24 January 2014 09:00 UTC

Return-Path: <mehmet.karaca@airties.com>
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 93E321A01DD for <tcmtf@ietfa.amsl.com>; Fri, 24 Jan 2014 01:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.635
X-Spam-Level:
X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 2YMcPUiX6AeT for <tcmtf@ietfa.amsl.com>; Fri, 24 Jan 2014 01:00:27 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id ED1B51A0199 for <tcmtf@ietf.org>; Fri, 24 Jan 2014 01:00:26 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id e49so828367eek.1 for <tcmtf@ietf.org>; Fri, 24 Jan 2014 01:00:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NfhHTOChefrGG2UvWLuAgpbQXh8T7WXEvVNQJJANg7w=; b=OP0UAHS9ph/JeO6+qn8wUrwVAmRD9ouXuB0BEbruyNy1zl94LZfTbgXunCQ6TBNB3K Z3wLeBxsoKI7khfWD7RA1owW5fswjmD+nfz6e7PYodrRGs8G2HJvjprCYQwM2cJUOZjd +HJhk/N90N0xerAOdN4TjJ5Kkc91rusUepuNoWGzzIsjeY8bL+PpM1tL5wDB5IE8pyM6 bep12ZdtvFhSKfUeMg4ryn30hklE6+cKbRIxzl/05LZfnuCT4VLLxfSEhgSRtk/lbDwu +rWr7ViLE1X8S74eIQl4akEAWObPEjzZyuLu31v2oSEUtbh2uJEYXsHaaylvIx7TJv0u Johw==
X-Gm-Message-State: ALoCoQmO/TpFYflP2lhg1Cpn5QBz1lRcOiN1mVNDj06YBSuumrFTdbjM4KrAi0JIMGK5bgQHsQyEzv0Bwz1iKL8JKzTNgTM1Rw==
MIME-Version: 1.0
X-Received: by 10.15.109.196 with SMTP id cf44mr11325284eeb.12.1390554025416; Fri, 24 Jan 2014 01:00:25 -0800 (PST)
Received: by 10.14.4.130 with HTTP; Fri, 24 Jan 2014 01:00:25 -0800 (PST)
In-Reply-To: <mailman.1540.1390544655.2325.tcmtf@ietf.org>
References: <mailman.1540.1390544655.2325.tcmtf@ietf.org>
Date: Fri, 24 Jan 2014 11:00:25 +0200
Message-ID: <CAMEqBMHAtStgKuGXLKpEsMvwaMJWUkmwJdLmLxRYeYmY4Hq_1w@mail.gmail.com>
From: Mehmet Karaca <mehmet.karaca@airties.com>
To: tcmtf@ietf.org
Content-Type: multipart/alternative; boundary="089e016814ccb9eb3b04f0b396b7"
Subject: Re: [tcmtf] tcmtf Digest, Vol 19, Issue 13
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 24 Jan 2014 09:00:32 -0000

Dear All,
Sorry for re-sending this message,

I completely support the formation of the WG for TCM-TF.  I believe that
such protocols in TCMMF will be also  beneficial from  MAC layer point of
view since whenever QoS is required and traffic is not tagged at MAC layer
(in cases where 802.11e is not supported or traffic is not tagged at the
source), traffic classification at  higher layer (Layer 3 or above) will be
very crucial for some level of  QoS at MAC layer.

Best Regards and  thanks!


Mehmet.


On Fri, Jan 24, 2014 at 8:24 AM, <tcmtf-request@ietf.org> wrote:

> Send tcmtf mailing list submissions to
>         tcmtf@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/tcmtf
> or, via email, send a message with subject or body 'help' to
>         tcmtf-request@ietf.org
>
> You can reach the person managing the list at
>         tcmtf-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tcmtf digest..."
>
> Today's Topics:
>
>    1. Re: tcmtf Digest, Vol 19, Issue 11 (Charles Oloo)
>
>
> ---------- Forwarded message ----------
> From: Charles Oloo <oloo6382@gmail.com>
> To: tcmtf@ietf.org
> Cc:
> Date: Fri, 24 Jan 2014 09:24:09 +0300
> Subject: Re: [tcmtf] tcmtf Digest, Vol 19, Issue 11
> Dear All
>
> I wish to convey support the creation of the TCM-TF WG in totality as it
> will mostly benefit the communities in developing countries where the
> internet and bandwidth if expensive, especially here in Kenya where
> internet usage is growing at tremendous speeds. The current gov plans for
> free laptops for primary schools will further increase the need for more
> bandwidth hence there is need to start looking at opportunities and means
> to avail and sustain the ambitious program. This is a challenge for some of
> us who can undertake initiatives to provide solutions for the communities.
>
> Regards
> Charles Oloo
>
>
> On Thu, Jan 23, 2014 at 6:05 PM, <tcmtf-request@ietf.org> wrote:
>
>> Send tcmtf mailing list submissions to
>>         tcmtf@ietf.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://www.ietf.org/mailman/listinfo/tcmtf
>> or, via email, send a message with subject or body 'help' to
>>         tcmtf-request@ietf.org
>>
>> You can reach the person managing the list at
>>         tcmtf-owner@ietf.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of tcmtf digest..."
>>
>> Today's Topics:
>>
>>    1. TCM-TF 2nd BoF approved (Jose Saldana)
>>    2. Re: TCMTF-Feedback about a possible BoF in London
>>       (Mehmet Karaca (Alumni))
>>
>>
>> ---------- Forwarded message ----------
>> From: "Jose Saldana" <jsaldana@unizar.es>
>> To: <tcmtf@ietf.org>
>> Cc: tsv-area@ietf.org
>> Date: Thu, 23 Jan 2014 11:17:00 +0100
>> Subject: [tcmtf] TCM-TF 2nd BoF approved
>>
>> Hi all,
>>
>>
>>
>> As you may know, the second TCM-TF BoF has been approved, and it will be
>> held in London next March.
>>
>>
>>
>> http://trac.tools.ietf.org/bof/trac/wiki#Transport
>>
>>
>>
>> We will work in the next weeks in order to prepare it well.
>>
>>
>>
>> Best regards and thanks,
>>
>>
>>
>> Jose
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "Mehmet Karaca (Alumni)" <mehmetkrc@sabanciuniv.edu>
>> To: FERNANDO PASCUAL BLANCO <fpb@tid.es>
>> Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, Tina TSOU <
>> Tina.Tsou.Zouting@huawei.com>, "Black, David" <david.black@emc.com>,
>> Jose Saldana <jsaldana@unizar.es>, "tsv-area@ietf.org" <tsv-area@ietf.org>,
>> Luigi Iannone <ggx@gigix.net>, Martin Stiemerling <
>> mls.ietf@googlemail.com>
>> Date: Thu, 23 Jan 2014 17:05:37 +0200
>> Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London
>> Dear All,
>>
>> I completely support the formation of the WG for TCMMF.  I believe that
>> such protocols in TCMMF will be also  beneficial from  MAC layer point of
>> view since whenever QoS is required and traffic is not tagged at MAC layer
>> (in cases where 802.11e is not supported or traffic is not tagged at the
>> source), traffic classification at  higher layer (Layer 3 or above) will be
>> very crucial for some level of  QoS at MAC layer.
>>
>> Best Regards and  thanks!
>>
>> Mehmet.
>>
>>
>> On Thu, Jan 9, 2014 at 7:49 PM, FERNANDO PASCUAL BLANCO <fpb@tid.es>wrote:
>>
>>>  Hi all,
>>>
>>>  Just to say that I also completely support the creation of the WG.
>>> There is no doubt that network protocols have evolved, and not always as we
>>> thought, and TCRTP needs to be wider.
>>>
>>> Regards,
>>> Fernando
>>>
>>>
>>>  On 09/01/2014, at 01:49, Tina TSOU <Tina.Tsou.Zouting@huawei.com>
>>> wrote:
>>>
>>>   Dear all,
>>> I'm in favor of having a BoF in London, as the following problem
>>> statement seems valid and needs protocol work in IETF.
>>> ---
>>>  In addition to VoIP, in the last years we are witnessing the raise of
>>> new real-time services e.g. videoconferencing, telemedicine, video
>>> vigilance, online gaming, etc.
>>>
>>>
>>>  Due to the need of interactivity, many of these services use small
>>> packets (some tens of bytes), since they have to send frequent updates
>>> between the extremes of the communication. Their small data payloads incur
>>> significant overhead, and it becomes even higher when IPv6 is used, since
>>> the basic IPv6 header is twice the size of the IPv4 one.
>>>
>>>
>>>  In the moments or places where network capacity gets scarce,
>>> allocating more bandwidth is a possible solution, but it implies a
>>> recurring cost. However, the inclusion of a pair of boxes able to optimize
>>> the traffic (reducing bandwidth and packets per second) when/where required
>>> is a one-time investment. We can do these three things:
>>>
>>>
>>>  a) header compression algorithms (e.g. ROHC) can be used for reducing
>>> the overhead of each flow;
>>>  b) at the same time, tunneling can be used in order to allow the
>>> header-compressed packets to travel end-to-end
>>>  c) compressed packets belonging to different flows can be multiplexed
>>> together, in order to share the tunnel overhead.
>>>
>>>
>>>  These emerging real-time services which use bare UDP instead of
>>> UDP/RTP have become popular. In addition, a significant effort has been
>>> devoted to the deployment of new header compression methods with improved
>>> robustness (ROHC). So there is a need of widening the scope of RFC4170 in
>>> order to consider these new header compression methods, and also UDP in
>>> addition to UDP/RTP.
>>>
>>>
>>>  As a result, the next objectives can be achieved:
>>>
>>>
>>>  * Significant bandwidth reductions (as an example, bandwidth savings
>>> of 55% can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For
>>> certain online games, 33% of the bandwidth can be saved for IPv4, and 55%
>>> when using IPv6).
>>>
>>>
>>>  * A reduction of the amount of packets per second managed by the
>>> network. A reduction factor of 10 or 20 can easily be achieved. This can be
>>> translated into smaller processing delays and energy savings in
>>> intermediate routers.
>>>  ---
>>>
>>>  Thank you,
>>> Tina
>>>
>>> On Jan 8, 2014, at 4:11 PM, "Jose Saldana" <jsaldana@unizar.es> wrote:
>>>
>>>   Hi all.
>>>
>>>  First of all, thanks to David and Luigi for their valuable comments.
>>>
>>>  I will wait for a while in order to include David’s comments (perhaps
>>> some other people has more suggestions).
>>>
>>>  These are the improvements of version 10 with respect to v9 (
>>> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.html)
>>>
>>>  - I have shortened paragraph 1.
>>>  - I have shortened and merged paragraphs 2 and 3.
>>>  - I have moved paragraph 4 to the third place, in order to set clearer
>>> what we want: replacing RFC4170 with a widened proposal. As David
>>> suggested, I have also shortened the text and it is now more
>>> straightforward.
>>>  - I have clearly stated which protocols will be used on each layer.
>>> The negotiation mechanism is still necessary, since different options are
>>> considered e.g. for header compression. The one to be used will depend on
>>> the scenario and the processing capacity of the two optimizers.
>>>  - I have significantly shortened the description of the scenarios.
>>>  - I have removed paragraph 6, which included the savings figures.
>>>  - I have included the replacement of RFC4170 in the first milestone.
>>>
>>>  Thanks!
>>>
>>>  Jose
>>>
>>>   *De:* Black, David [mailto:david.black@emc.com <david.black@emc.com>]
>>> *Enviado el:* sábado, 04 de enero de 2014 4:05
>>> *Para:* Jose Saldana; tcmtf@ietf.org; tsv-area@ietf.org
>>> *CC:* Martin Stiemerling; Black, David
>>> *Asunto:* RE: TCMTF-Feedback about a possible BoF in London
>>>
>>>  A second BoF has the explicit goal of forming a WG, as a third BoF
>>>  is not permitted.  In that regard, the new charter seems long and
>>>  somewhat lacking in focus.  Two key things I look for in a proposed
>>>  charter are what problem (or problems) the proposed WG is looking to
>>>  solve and an initial approach to the problem or problems.
>>>
>>>  In the new draft charter, the problem statement appears to be in
>>>  paragraph 4 with paragraph 1 providing important background.  The
>>>  focus of the work appears to be on extending TCRTP (RFC 4170) to
>>>  UDP and to include new compression protocols.  In contrast, I have
>>>  a hard time discerning the initial approach from the new draft charter.
>>>
>>>  In light of this, there are a few things that I wish the new
>>>  draft charter had definitive proposals for:
>>>
>>>        a) Whether to replace RFC 4170 vs. write a new RFC (could be
>>>              UDP-only or UDP + RTP/UDP) as a complement to RFC 4170.
>>>        b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507
>>> ?).
>>>              Non-use of ECRTP would be a major change to 4170, and I
>>>  wonder about IPHC, as opposed to the ROHCv2 profiles.
>>>        c) Analogies to b) for the Mux and Tunnel layers of the stack.
>>>
>>>  Overall, it looks like the first task of the WG is to select the
>>> protocol
>>>  stack to standardize - I have misgivings about that, and would prefer
>>> to
>>>  see a concrete proposal in a crisp charter that ran along the following
>>>  lines, naming the protocols to be used:
>>>
>>>  1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z.
>>>  2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C.
>>>
>>>  A specific proposal or proposals for the protocol stack or stacks
>>>  would also narrow the scope of item 9 in the charter on the negotiation
>>>  mechanism.  I also don’t see a goal/milestone listed for an extension
>>> to
>>>  or replacement for RFC 4170.
>>>
>>>  I’d prefer to see a much shorter more focused draft charter.  There’s a
>>>  bunch of background material that does not seem crucial to the charter,
>>>  starting w/paragraphs 2 and 3.
>>>
>>>  Thanks,
>>> --David
>>>
>>>   *From:* tsv-area [mailto:tsv-area-bounces@ietf.org<tsv-area-bounces@ietf.org>
>>> ] *On Behalf Of *Jose Saldana
>>> *Sent:* Friday, December 20, 2013 4:26 AM
>>> *To:* tcmtf@ietf.org; tsv-area@ietf.org
>>> *Cc:* Martin Stiemerling
>>> *Subject:* TCMTF-Feedback about a possible BoF in London
>>>
>>>  Hi all,
>>>
>>>  After the feedback received in the BoF in Berlin, we have updated the
>>> TCM-TF charter and the two drafts. We have tried to solve all the problems
>>> raised during the session.
>>>
>>>  Our plan is to request a new BoF in London next March, so we would
>>> like to know your opinion about these two questions:
>>>
>>>
>>>  1.  Is the new, reduced scope of TCM-TF suitable to form a working
>>> group?
>>>
>>>
>>>  2. We would like to kindly ask people who think that a TCM-TF Working
>>> group should be formed, to come forward and send an e-mail to the
>>> tsv-area@ietf.org  mailing list stating it.
>>>
>>>
>>>  This feedback will allow us to get a better idea of the convenience of
>>> a BoF.
>>>
>>>  The new charter is here:
>>> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html
>>>  This is the old one (presented in Berlin):
>>> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html
>>>
>>>  In these links you can see the differences between the new versions of
>>> the drafts and the old ones:
>>>
>>> http://tools.ietf.org/rfcdiff?url1=draft-saldana-tsvwg-tcmtf-06.txt&url2=draft-saldana-tsvwg-tcmtf-05.txt
>>>
>>> http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt&url2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt
>>>
>>>
>>>  The main improvements are:
>>>
>>>  - TCP optimization has been removed
>>>  - The classification of the scenarios has been refined and improved.
>>> Some of them have been removed
>>>  - A section about energy consumption has been added to the main draft
>>>  - A reference to the potential problem of the MTU and packet loss has
>>> been added
>>>  - The problem of the added delays is studied in detail in the second
>>> draft
>>>
>>>  - The improvements of the charter are summarized here:
>>> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html
>>>
>>>
>>>  Best regards,
>>>
>>>  Jose
>>>
>>>
>>>   _______________________________________________
>>>
>>> tcmtf mailing list
>>> tcmtf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>> nuestra política de envío y recepción de correo electrónico en el enlace
>>> situado más abajo.
>>> This message is intended exclusively for its addressee. We only send and
>>> receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>
>>> _______________________________________________
>>> tcmtf mailing list
>>> tcmtf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>
>>>
>>
>> _______________________________________________
>> tcmtf mailing list
>> tcmtf@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcmtf
>>
>>
>
>
> --
> Charles Oloo
> WEBMASTER
> Tel: +254 721 909757
>
>
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf
>
>


-- 
-- 

Mehmet Karaca, PhD

System Engineer, CTO Office

AirTies Wireless Networks (www.airties.com)



M: +90 (554) 718  9009

E: mehmet.karaca@airties.com <ece.gelal@airties.com>

-- 

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views 
expressed may not be official policy, but the personal views of the 
originator. If you have received it in error, please notify the sender by 
return e-mail and delete it from your system. You should not reproduce, 
distribute, store, retransmit, use or disclose its contents to anyone.