All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [dccp] Question on resetting nominal send time
Date: Fri, 19 Jan 2007 15:49:30 +0000	[thread overview]
Message-ID: <45B0E88A.3060302@erg.abdn.ac.uk> (raw)
In-Reply-To: <5640c7e00701161351q19360335mf2862a31596ae94a@mail.gmail.com>

Ian,

I can see what you are saying, and indeed this is an interesting problem 
area, in that it impacts what we understand as correct behaviour, but 
also impinges on what we may accept as accceptable implementation cost.

I'll let others figure out their advice to you...

Gorry

Ian McDonald wrote:

> Folks,
> 
> While Gerrit and I have been refining the CCID3 implementation in
> Linux we have noticed some issues around packet scheduling. I would
> like some clarification around this please as I can't find the answers
> in the RFCs. It may well be that I have just missed something obvious.
> 
> Section 4.6 of RFC3448 talks about calculating the nominal sending
> time being the previous nominal sending time plus t_ipi (inter packet
> interval).
> 
> The aim of this is to allow an average packet rate per second and
> section 4.6 explicitly allows bursts of traffic.
> 
> This generally works well except for two scenarios that I can think of:
> 
> 1) The application sends at less than the permitted rate. This means
> that the nominal send time becomes further and further in the past for
> the current packet. This means we can basically transmit whenever we
> want until we catch up in time. I would guess that this is not what is
> intended, particularly as it means it will take time to respond to the
> beginning of increased loss.
> 
> 2) The sender becomes idle. However there is no talk of resetting the
> nominal sending time. So if we are idle for 10 seconds then when we
> become active again we can send 10 seconds worth of packets
> instantaneously. I am guessing that this was also not the intent of
> the RFC authors.
> 
> Can some clarification please be provided or pointing out what I have
> missed in the RFCs?
> 
> I'm guessing there should be some mechanism for resending the nominal 
> send time.
> 
> Regards,
> 
> Ian


  reply	other threads:[~2007-01-19 15:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-16 21:51 Question on resetting nominal send time Ian McDonald
2007-01-19 15:49 ` Gorry Fairhurst [this message]
2007-02-08  0:29 ` [dccp] " Eddie Kohler
2007-02-08  0:39 ` Eddie Kohler
2007-03-05  9:49 ` Gerrit Renker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45B0E88A.3060302@erg.abdn.ac.uk \
    --to=gorry@erg.abdn.ac.uk \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.