Re: [Raw] New Version Notification for draft-theoleyre-raw-oam-support-02.txt

Rex Buddenberg <buddenbergr@gmail.com> Mon, 13 April 2020 18:13 UTC

Return-Path: <buddenbergr@gmail.com>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE8A3A1ADD for <raw@ietfa.amsl.com>; Mon, 13 Apr 2020 11:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZJlIJyfioD1h for <raw@ietfa.amsl.com>; Mon, 13 Apr 2020 11:12:58 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF7B3A1AE4 for <raw@ietf.org>; Mon, 13 Apr 2020 11:12:58 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id d17so4818035pgo.0 for <raw@ietf.org>; Mon, 13 Apr 2020 11:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=Ldkk5lSabjY+TRGhRQAWbMQuk2ojOAnS0cO80FRpAKQ=; b=J7rl9Msl3Hs0cl/TKb4yRFV32b1tj7Rww/c7Xw3mgs9GGEwlSBcxgOsvmq+1iiYwzn BSmSJK25z0bYjAJF7qWq0/S1Kru0bc6aU76/szoO9jOM3ZHocoh3u+laJWVoRPNv3iBI vsKj4tTWXLwCbdpq+F6UvNslZKyyq04syEC1lBjyo3LsXMaqwCMXHZv481lv9EaQbDBw HSt6dKsNOcZ6FKxL5P9G88jOCVLegI3sOLIKZ5Wb11Yy6pd1GMwPZADRbtKhmJrcd5La zlyF+TXLDjZpDxkIxbQETrqC4etQUfq6/BR5AH1TR/vRD7sk5/VCqU02BIHgvff/NDKF qo9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ldkk5lSabjY+TRGhRQAWbMQuk2ojOAnS0cO80FRpAKQ=; b=HN8KzhvXF5gubM8GBvhXzNiqizY2+8HWRb5cW/fEmwCCqh6O9wYJQj23E8lKClx5Kz vVM/uLiEZMzSpAztSAsDkCrphNjD0wU9wP2pk/XMYStUILFNzTZ60KPbU6JnQcUxIEQu xg1EAG8HY4L1VEQ9j6+vN2WzzIcU/kwV6xIJvZCMzxHxLD+sV5Ytesd0MlfSwEcrxmOo AbCq4QT1gM0uT28kGmTSF2jjfOVgnmm9JlCHSQrTyRZm0/LtX3l1kYqUO3H9Eyo2GWNP z3r2KDSeKsGod976IVksAJCqGdmMLAjllHHXAU0bbszvMzO/sqoSwDrape/pJf9393Qr sbwA==
X-Gm-Message-State: AGi0PuambbFH5PwrRQ4zOoV3b0w2sMaFzXDo15AjTUDfXql4i0wwdqMs PbbJTJVXGRuTcvGn0xOjgdZ2XVgS
X-Google-Smtp-Source: APiQypI1uMyA0ftcNF3r3zZpjtvKVNchaOImd+MPhI4yuUOGdG8zJTtwE9DE98vhW+Kd9cDIEOCTZw==
X-Received: by 2002:aa7:86c9:: with SMTP id h9mr15966984pfo.294.1586801577719; Mon, 13 Apr 2020 11:12:57 -0700 (PDT)
Received: from localhost.localdomain (c-73-241-197-249.hsd1.ca.comcast.net. [73.241.197.249]) by smtp.gmail.com with ESMTPSA id x4sm9195900pfi.202.2020.04.13.11.12.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Apr 2020 11:12:56 -0700 (PDT)
Message-ID: <1586801575.2208.44.camel@gmail.com>
From: Rex Buddenberg <buddenbergr@gmail.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>, John Grant <j@ninetiles.com>
Cc: raw@ietf.org
Date: Mon, 13 Apr 2020 11:12:55 -0700
In-Reply-To: <CADnDZ89=cY3f4RsaDh-v0uF=69UkE6V6QHZnAhHGoaqr=WX-4w@mail.gmail.com>
References: <158661318544.14084.5863836622249108176@ietfa.amsl.com> <4F7B9B43-11FB-4D0A-8B90-AA1EB8BAA1FB@unistra.fr> <1586753172.2208.35.camel@gmail.com> <f4571ad6-b7ea-e9f4-cf95-149268137648@ninetiles.com> <CADnDZ89=cY3f4RsaDh-v0uF=69UkE6V6QHZnAhHGoaqr=WX-4w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/KtzgaXcotmncJG3QCSTPljxhBbI>
Subject: Re: [Raw] New Version Notification for draft-theoleyre-raw-oam-support-02.txt
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2020 18:13:01 -0000

Ethernet, for example, has a frame check sequence and a link-level (aka
layer 2) retransmit on error.  Back in the '80s there were some
experiments (by radio amateurs if memory serves) that found that end-
end (layer 4) error control was more efficient than per hop.
Nonetheless both exist.  
  John, you are correct -- TCP detected a missing packet but it had no
idea why the packet was missing. And the reactions (partially shutting
the send window) assumed that a missing packet was caused by congestion
(e.g. router queue overflow). That, of course, is a pretty naive, and
often wrong, conclusion. Especially in wireless.  
  If I'm reading what the OAM folks on this list are telling us is that
we need more information -- more 'why' in the missing packet event???
For that, you're gonna want to bore down into base station MAC
operations (via the MIB values).
  My intent here is to fix the wording in the draft to avoid attracting
the protocol police.



On Mon, 2020-04-13 at 15:31 +0200, Abdussalam Baryun wrote:
> 
> 
> On Mon, Apr 13, 2020 at 12:44 PM John Grant <j@ninetiles.com> wrote:
> > On 13/04/2020 05:46, Rex Buddenberg wrote:
> > > > Thus, providing
> > > >    availability and reliability on top of the wireless
> > > > infrastructure
> > > >    requires specific layer 3 mechanisms to counteract these
> > > > bursty
> > > >    losses.
> > > Where I was raised, layer 4 was where reliability mechanisms
> > > (e.g. TCP)
> > > were to be found. TCP is very good at counteracting bursty
> > > losses.
> > >   The other place that bursty losses can be countered is at layer
> > > 1
> > > utilizing Forward Error Correction (FEC) techniques. In my
> > > experience
> > > in MF, LF, HF radio they can be quite effective, albeit
> > > bandwidth-
> > > expensive.
> >  In cellular there is also acknowledge/retransmit in the lower
> > layers; I guess it'd be layer 2 so still not layer 3. One issue the
> > mobile industry has is that TCP assumes a packet that gets through
> > at the second attempt has been delayed by congestion, and reacts
> > inappropriately.
> For RAW technology there needs to be reliable technique in L1 or L2
> so that we can call it reliable wireless. In cellular it is reliable
> techniques.
> 
> AB
> -- 
> RAW mailing list
> RAW@ietf.org
> https://www.ietf.org/mailman/listinfo/raw