[xml2rfc] Question about tables

fred at cisco.com (Fred Baker) Fri, 28 July 2006 11:55 UTC

From: fred at cisco.com (Fred Baker)
Date: Fri, 28 Jul 2006 11:55:26 +0000
Subject: [xml2rfc] Question about tables
Message-ID: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
X-Date: Fri Jul 28 11:55:26 2006

I have implemented a table in the attached beginnings of a document.  
Don't think too hard about what the document is about; it is  
basically a request for a hop-by-hop option number for experimental  
use in a protocol extension that I think has promise but needs a lot  
of work.

There is a graphic that describes the hop-by-hop option, and then a  
table that talks in more detail about the fields in it. The table  
comes out the way I want it to look in the html version, but in the  
text version I think it needs some lines to make it look better.  
Suggestions on how to get the tool to produce them?

     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop-edited.txt
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.html
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.txt
     ftp://ftpeng.cisco.com/fred/xml2rfc/RCP-Hop-by-hop.xml

The "edited" file is approximately what I would like the text of the  
table to come out looking like. It is manually edited. I suppose I  
could do that and then put it into an "artwork" block, but it would  
be nice if I didn't have to.
>From Nicolas.Williams at sun.com  Fri Jul 28 15:15:37 2006
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Jul 28 12:15:45 2006
Subject: [xml2rfc] Question about tables
In-Reply-To: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
References: <CD9382A8-3CC3-4442-8A66-5EC6D7D2761A@cisco.com>
Message-ID: <20060728191537.GQ11384@binky.Central.Sun.COM>

On Fri, Jul 28, 2006 at 11:55:19AM -0700, Fred Baker wrote:
> There is a graphic that describes the hop-by-hop option, and then a  
> table that talks in more detail about the fields in it. The table  
> comes out the way I want it to look in the html version, but in the  
> text version I think it needs some lines to make it look better.  
> Suggestions on how to get the tool to produce them?

I was just about to ask the same question: how to get dash lines between
rows of tables in xml2rfc txt output?  Or is the lack of dash lines
between rows a bug?

I've got a draft which includes suggested forms for IANA registrations,
these being modelled as texttables; the lack of clear breaks between
rows makes it hard to read these forms...

Nico
-- 
>From fred at cisco.com  Thu Jul 27 23:30:21 2006
From: fred at cisco.com (Fred Baker)
Date: Fri Jul 28 23:18:41 2006
Subject: [xml2rfc] Question about tables
Message-ID: <A4BBFE35-7D0C-4202-A083-DC05C2A2EC7E@cisco.com>

I have implemented a table in the attached beginnings of a document.  
It comes out the way I want it to look in the html version, but in  
the text version I think it needs some lines to make it look better.  
Suggestions on how to get the tool to produce them?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.html
-------------- next part --------------



IPv6                                                        N. Dukkipati
Internet-Draft                                       Stanford University
Intended status: Informational                                  F. Baker
Expires: January 28, 2007                                  Cisco Systems
                                                           July 27, 2006


         Implementing RCP in the IPv6 Hop-by-Hop Options Header
                        draft-baker-document-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 28, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This note describes the implementation of RCP as an IPv6 Hop-by-Hop
   option.








Dukkipati & Baker       Expires January 28, 2007                [Page 1]

Internet-Draft               RCP Hop-by-Hop                    July 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The Hop-by-hop Option supporting RCP  . . . . . . . . . . . . . 3
     2.1.  Defining the option . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Router calculations to be performed . . . . . . . . . . . . 5
       2.2.1.  Router calculations to be performed periodically  . . . 5
       2.2.2.  Router calculations to be performed per packet  . . . . 5
   3.  Design caveats  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Behavior around tunnels . . . . . . . . . . . . . . . . . . 6
     3.2.  Initial conditions  . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Layer violations  . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Additional stuff . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9






























Dukkipati & Baker       Expires January 28, 2007                [Page 2]

Internet-Draft               RCP Hop-by-Hop                    July 2006


1.  Introduction


2.  The Hop-by-hop Option supporting RCP

2.1.  Defining the option



                0 1 2 3 4 5 6 7 8             15
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Option Type  |  Opt Data Len |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | BW Request
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | BW Response
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Exp      |  Mantissa         | RTT Estimate
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 1: RCP Hop-by-Hop Option





























Dukkipati & Baker       Expires January 28, 2007                [Page 3]

Internet-Draft               RCP Hop-by-Hop                    July 2006


                 The fields in the header are as follows:

   +-----------+-------+-------------+---------------------------------+
   |   Field   |  Bits |    Range    |           Description           |
   +-----------+-------+-------------+---------------------------------+
   |    Type   |  0..7 | RCPHopByHop |      RCP Hop-by-Hop Option      |
   |  Data Len | 8..15 |      6      |       Payload is six bytes      |
   | Bandwidth |       |             | Bits per second the application |
   |  Request  |       |             |    would like to transmit at    |
   |  B/W Req  |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |  B/W Req  | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   | Bandwidth |       |             | Bits per second the network can |
   |  Response |       |             |     support the application     |
   |           |       |             |         transmitting at         |
   |  B/W Rsp  |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |  B/W Rsp  | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   |    RTT    |       |             |     Mean RTT in Milliseconds    |
   |  Estimate |       |             |                                 |
   |    B/W    |  0..5 |    0..63    |                                 |
   |  Exponent |       |             |                                 |
   |    B/W    | 6..15 |   0..1023   |                                 |
   |  Mantissa |       |             |                                 |
   +-----------+-------+-------------+---------------------------------+

                 Table 1: Fields in RCP Hop-by-Hop Option

   The premise is that any relevant number can be approximately
   represented as a "mantissa" (an integer) shifted left "exponent" bits
   (e.g., mantissa<<exponent, or mantissa*2^exponent).  IEEE Standard
   754 floating-point representation was considered as well, but it
   consumes more bits, and network devices frequently do not directly
   support it.  This can be implemented in a few gates in hardware, or a
   few instructions in microcode.

   Two special numbers are defined: Infinity and Zero.  Clearly any
   number with a mantissa of zero has the value zero; implementations
   are encouraged to represent with an exponent of zero as well (e.g.,
   16 bits, all zero).  The number with an exponent of 63 and a mantissa
   of 1023 (e.g., sixteen bits, all ones) indicates an unknown or
   unspecified value.

   Specifically, when a TCP implementation sends a SYN packet, at that
   time it has no measurement of the RTT to the peer and no knowledge of
   network capacity.  It may be able to say something about what it



Dukkipati & Baker       Expires January 28, 2007                [Page 4]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   would like to send, such as perhaps indicating the bit rate of the
   relevant interface.  On a SYN, therefore, the sender may indicate a
   requested rate, but the rate response and RTT are unspecified.
   Similarly, when sending a SYN-ACK, the system may know the response
   rate if this option was present in the SYN packet, but it does not
   know the RTT, and so must indicate that the RTT is unspecified.
   Subsequent datagrams in the exchange have the required information,
   and so may indicate it.

2.2.  Router calculations to be performed

2.2.1.  Router calculations to be performed periodically

   The router is intended to periodically (approximately once per
   average RTT of sessions passion through it, but more frequently if
   appropriate) calculate how much bandwidth it can allocate to the
   average data flow.  The way it accomplishes this is defined in
   [Nandita].

2.2.2.  Router calculations to be performed per packet

2.2.2.1.  Router calculations to be performed on each packet packet

   If the rate being requested in any given packet is unspecified or
   exceeds the bandwidth being granted to data flows in the specified
   class, then it should be set to that value.

2.2.2.2.  Router calculations to be performed per packet

   The advertised RTT, specified, should be averaged into the current
   RTT estimate.


3.  Design caveats

   RCP, in using the option described in Section 2, has several issues
   that will need to be addressed as it is fleshed out.  These relate to

   o  Behavior around tunnels

   o  initial conditions

   o  layer violations








Dukkipati & Baker       Expires January 28, 2007                [Page 5]

Internet-Draft               RCP Hop-by-Hop                    July 2006


3.1.  Behavior around tunnels

   The Internet uses a wide variety of tunneling architectures.  These
   include, but are not limited to:

   o  MPLS [RFC3031]

   o  Generalized MPLS [RFC3945], which is used for lambda switching

   o  L2TP [RFC2661]

   o  IP-in-IP [RFC1853]

   o  GRE Tunnels [RFC2784]

   o  IPSEC ESP in Tunnel Mode [RFC4301][RFC4301].

   As discussed in [RFC2983], issues can arise with traffic passing
   through opaque regions created by tunnels; information is not
   accumulated in the inside headers, and if it is accumulated in the
   outside headers it may or may not be copied to the inside headers on
   decapsulation.

3.2.  Initial conditions

   As discussed in Section 2.1, the initial conditions for a data flow
   are unknown.  For example, until the RTT on a session has been
   measured, it is invalid for the sender to advise the network of his
   RTT.  There may be other issues with initial conditions.

3.3.  Layer violations

   A special case of an initial condition problem occurs if the
   transport layer specifies the rate requested in the option.  Some
   transports know that their applications will send at stated rates,
   such as codecs; this rate can be specified to them by the
   application.  In many elastic traffic cases, the logical rate to
   request is the bit rate of the interface that the data will flow
   from.  However, on any device that has multiple interfaces (routers
   in general and many hosts as well), the interface is chosen in the
   network layer after the transport has chosen an address.  In such
   cases, the transport has no a priori knowledge of the interface rate,
   as the appropriate interface has not been chosen.


4.  IANA Considerations

   This memo requests the allocation of a hop-by-hop option, as defined



Dukkipati & Baker       Expires January 28, 2007                [Page 6]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   in [RFC2460].  The number should be in the range 0..63, as it is an
   option which if not understood should be ignored and passed along.
   The RFC Editor should replace this section with a statement reporting
   the value that has been assigned to the literal RPCHopByHop.


5.  Security Considerations


6.  Acknowledgements


7.  References

7.1.  Normative References

   [Nandita]  Dukkipati, N. and N. McKeown, "RCP-AC: Congestion Control
              to make flows complete quickly in any environment", 2006,
              <http://yuba.stanford.edu/rcp/RCP_AC-dukkipati.pdf>.

   [Nandita-1]
              Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N.
              McKeown, "Processor Sharing Flows in the Internet", 2004,
              <http://yuba.stanford.edu/tr.html>.

   [Nandita-2]
              Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is
              the Right Metric for Congestion Control", 2006, <http://
              yuba.stanford.edu/techreports/TR05-HPNG-112102.pdf>gt;.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

7.2.  Informative References

   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, October 2000.




Dukkipati & Baker       Expires January 28, 2007                [Page 7]

Internet-Draft               RCP Hop-by-Hop                    July 2006


   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.


Appendix A.  Additional stuff


Authors' Addresses

   Nandita Dukkipati
   Stanford University
   Palo Alto, California
   USA

   Phone:
   Email: nanditad@stanford.edu


   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1-408-526-4257
   Email: fred@cisco.com




















Dukkipati & Baker       Expires January 28, 2007                [Page 8]

Internet-Draft               RCP Hop-by-Hop                    July 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Dukkipati & Baker       Expires January 28, 2007                [Page 9]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCP-Hop-by-hop.xml
Type: text/xml
Size: 17031 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20060727/543bbdde/RCP-Hop-by-hop-0001.xml
>From julian.reschke at gmx.de  Sun Jul 30 21:31:46 2006
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun Jul 30 11:32:12 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
Message-ID: <44CCFB12.20806@gmx.de>

Hi,

are are two minor issues:

1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't declare 
the submissionType attribute (this probably applies to the other files 
derived from the DTD as well).

2) rfc2629-xhtml.ent declares character entities for the five entities 
that are hardwired into XML. This causes the XML parser over here to 
issue warnings every time a document referencing the DTD is parsed. 
Please get rid of them.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Jul 31 11:09:12 2006
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jul 31 00:09:23 2006
Subject: [xml2rfc] Minor 1.31 nits (DTD)
In-Reply-To: <44CCFB12.20806@gmx.de>
References: <44CCFB12.20806@gmx.de>
Message-ID: <A0F7001F-FF0B-49F6-B386-B01B9FB50C5C@dbc.mtview.ca.us>

> 1) rfc2629.rnc isn't up-to-date with the current DTD; it doesn't  
> declare the submissionType attribute (this probably applies to the  
> other files derived from the DTD as well).

fixed.


> 2) rfc2629-xhtml.ent declares character entities for the five  
> entities that are hardwired into XML. This causes the XML parser  
> over here to issue warnings every time a document referencing the  
> DTD is parsed. Please get rid of them.

send me a new file in a .zip or .tgz

thanks,

/mtr